Nabble - gcc - Dev

Re: target hooks / plugins

2009-12-23T16:32:44Z

Quoting Joern Rennecke <amylaar@...>:

> Right now, to make a new target hook, you have to add a new field in
> target.h, define a new default in target-def.h, place the new macro
> in exactly the right position there of the right initializer macro,
> describe the new hook in tm.texi, and if you need a new function with
> a bunch of parameters returning a constant, you have to add this to
> hooks.c .
>
> I would like to be able to do all this by adding a single entry in a
> new definition file; and the information should also be usable by
> plugin sources so that they can automatically make wrappers for all
> function-type hooks.

I've attached what I have so far.
There is an issue that the struct gcc_target member names don't always agree
with the TARGET_* macro names.

Should I rather change one or the other to make them agree, or add an extra
parameter in the definition file macros to specify these names independently?

Index: target.def
===================================================================
--- target.def (revision 0)
+++ target.def (revision 0)
@@ -0,0 +1,263 @@
+/* Target hook definitions.
+ Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
+ Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 3, or (at your option) any
+ later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; see the file COPYING3. If not see
+ <http://www.gnu.org/licenses/>.
+
+ In other words, you are welcome to use, share and improve this program.
+ You are forbidden to forbid anyone else to use, share and improve
+ what you give them. Help stamp out software-hoarding! */
+
+/* The following macros should be provided by the including file:
+
+ DEFHOOK(NAME, DOC, TYPE, PARAMS, INIT): Define a function-valued hook.
+ DEFHOOKPOD(DOC, TYPE, NAME, INIT): Define a piece-of-data 'hook'. */
+
+/* Defaults for optional macros:
+ DEFHOOKPODX(NAME, NAME, INIT): Like DEFHOOKPOD, but share documentation
+ with the previous 'hook'. */
+#ifndef DEFHOOKPODX
+#define DEFHOOKPODX(NAME, TYPE, INIT) DEFHOOKPOD (NAME, 0, TYPE, INIT)
+#endif
+
+/* HOOKSTRUCT(FRAGMENT): Declarator fragments to encapsulate all the
+ members into a struct gcc_target, which in turn contains several
+ sub-structs. */
+#ifndef HOOKSTRUCT
+#define HOOKSTRUCT(FRAGMENT)
+#endif
+
+HOOKSTRUCT (struct gcc_target {)
+
+/* Functions that output assembler for the target. */
+#define HOOK_PREFIX "TARGET_ASM_"
+HOOKSTRUCT (struct asm_out {)
+
+DEFHOOKPOD
+(open_paren,
+"These target hooks are C string constants, describing the syntax in the\
+ assembler for grouping arithmetic expressions. If not overridden, they\
+ default to normal parentheses, which is correct for most assemblers.",
+ const char *, "(")
+DEFHOOKPODX (close_paren, const char *, ")")
+
+DEFHOOKPOD
+(byte_op,
+"@deftypevrx {Target Hook} {const char *} TARGET_ASM_ALIGNED_HI_OP\n"
+"@deftypevrx {Target Hook} {const char *} TARGET_ASM_ALIGNED_SI_OP\n"
+"@deftypevrx {Target Hook} {const char *} TARGET_ASM_ALIGNED_DI_OP\n"
+"@deftypevrx {Target Hook} {const char *} TARGET_ASM_ALIGNED_TI_OP\n"
+"@deftypevrx {Target Hook} {const char *} TARGET_ASM_UNALIGNED_HI_OP\n"
+"@deftypevrx {Target Hook} {const char *} TARGET_ASM_UNALIGNED_SI_OP\n"
+"@deftypevrx {Target Hook} {const char *} TARGET_ASM_UNALIGNED_DI_OP\n"
+"@deftypevrx {Target Hook} {const char *} TARGET_ASM_UNALIGNED_TI_OP\n"
+"These hooks specify assembly directives for creating certain kinds\
+ of integer object. The @code{TARGET_ASM_BYTE_OP} directive creates a\
+ byte-sized object, the @code{TARGET_ASM_ALIGNED_HI_OP} one creates an\
+ aligned two-byte object, and so on. Any of the hooks may be\
+ @code{NULL}, indicating that no suitable directive is available.\n\n"
+
+"The compiler will print these strings at the start of a new line,\
+ followed immediately by the object's initial value. In most cases,\
+ the string should contain a tab, a pseudo-op, and then another tab.",
+ const char *, "\t.byte\t")
+DEFHOOKPOD
+(aligned_op, "*", struct asm_int_op,
+ ({ TARGET_ASM_ALIGNED_HI_OP, TARGET_ASM_ALIGNED_SI_OP,
+ TARGET_ASM_ALIGNED_DI_OP, TARGET_ASM_ALIGNED_TI_OP }) )
+DEFHOOKPOD
+(unaligned_op, "*", struct asm_int_op,
+ ({ TARGET_ASM_UNALIGNED_HI_OP, TARGET_ASM_UNALIGNED_SI_OP,
+ TARGET_ASM_UNALIGNED_DI_OP, TARGET_ASM_UNALIGNED_TI_OP }) )
+ /* Assembler instructions for creating various kinds of integer object. */
+
+DEFHOOK
+(integer,
+"The @code{assemble_integer} function uses this hook to output an\
+ integer object. @var{x} is the object's value, @var{size} is its size\
+ in bytes and @var{aligned_p} indicates whether it is aligned. The\
+ function should return @code{true} if it was able to output the\
+ object. If it returns false, @code{assemble_integer} will try to\
+ split the object into smaller parts.\n\n"
+
+"The default implementation of this hook will use the\
+ @code{TARGET_ASM_BYTE_OP} family of strings, returning @code{false}\
+ when the relevant string is @code{NULL}.",
+ /* Only handles cases for which BYTE_OP, ALIGNED_OP and UNALIGNED_OP are
+ NULL. */
+ bool, (rtx x, unsigned int size, int aligned_p),
+ default_assemble_integer)
+
+DEFHOOK
+(globalize_label,
+"This target hook is a function to output to the stdio stream\
+ @var{stream} some commands that will make the label @var{name} global;\
+ that is, available for reference from other files.\n\n"
+
+"The default implementation relies on a proper definition of\
+ @code{GLOBAL_ASM_OP}.",
+ void, (FILE *stream, const char *name),
+ default_globalize_label)
+
+DEFHOOK
+(globalize_decl_name,
+"This target hook is a function to output to the stdio stream\
+ @var{stream} some commands that will make the name associated with @var{decl}\
+ global; that is, available for reference from other files.\n\n"
+
+"The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL target hook.",
+ void, (FILE *stream, tree decl), default_globalize_decl_name)
+
+DEFHOOK
+(emit_unwind_label,
+"This target hook emits a label at the beginning of each FDE@. It \
+ should be defined on targets where FDEs need special labels, and it \
+ should write the appropriate label, for the FDE associated with the \
+ function declaration @var{decl}, to the stdio stream @var{stream}. \
+ The third argument, @var{for_eh}, is a boolean: true if this is for an \
+ exception table. The fourth argument, @var{empty}, is a boolean: \
+ true if this is a placeholder label for an omitted FDE@.\n\n"
+
+"The default is that FDEs are not given nonlocal labels.",
+ void, (FILE *stream, tree decl, int for_eh, int empty),
+ default_emit_unwind_label)
+
+#if 0
+ /* Output code that will emit a label to divide up the exception
+ table. */
+ void (* except_table_label) (FILE *);
+
+ /* Emit any directives required to unwind this instruction. */
+ void (* unwind_emit) (FILE *, rtx);
+
+ /* Output an internal label. */
+ void (* internal_label) (FILE *, const char *, unsigned long);
+
+ /* Emit a ttype table reference to a typeinfo object. */
+ bool (* ttype) (rtx);
+
+ /* Emit an assembler directive to set visibility for the symbol
+ associated with the tree decl. */
+ void (* visibility) (tree, int);
+
+ /* Output the assembler code for entry to a function. */
+ void (* function_prologue) (FILE *, HOST_WIDE_INT);
+
+ /* Output the assembler code for end of prologue. */
+ void (* function_end_prologue) (FILE *);
+
+ /* Output the assembler code for start of epilogue. */
+ void (* function_begin_epilogue) (FILE *);
+
+ /* Output the assembler code for function exit. */
+ void (* function_epilogue) (FILE *, HOST_WIDE_INT);
+
+ /* Initialize target-specific sections. */
+ void (* init_sections) (void);
+
+ /* Tell assembler to change to section NAME with attributes FLAGS.
+ If DECL is non-NULL, it is the VAR_DECL or FUNCTION_DECL with
+ which this section is associated. */
+ void (* named_section) (const char *name, unsigned int flags, tree decl);
+
+ /* Return a mask describing how relocations should be treated when
+ selecting sections. Bit 1 should be set if global relocations
+ should be placed in a read-write section; bit 0 should be set if
+ local relocations should be placed in a read-write section. */
+ int (*reloc_rw_mask) (void);
+
+ /* Return a section for EXP. It may be a DECL or a constant. RELOC
+ is nonzero if runtime relocations must be applied; bit 1 will be
+ set if the runtime relocations require non-local name resolution.
+ ALIGN is the required alignment of the data. */
+ section *(* select_section) (tree, int, unsigned HOST_WIDE_INT);
+
+ /* Return a section for X. MODE is X's mode and ALIGN is its
+ alignment in bits. */
+ section *(* select_rtx_section) (enum machine_mode, rtx,
+ unsigned HOST_WIDE_INT);
+
+ /* Select a unique section name for DECL. RELOC is the same as
+ for SELECT_SECTION. */
+ void (* unique_section) (tree, int);
+
+ /* Return the readonly data section associated with function DECL. */
+ section *(* function_rodata_section) (tree);
+
+ /* Output a constructor for a symbol with a given priority. */
+ void (* constructor) (rtx, int);
+
+ /* Output a destructor for a symbol with a given priority. */
+ void (* destructor) (rtx, int);
+
+ /* Output the assembler code for a thunk function. THUNK_DECL is the
+ declaration for the thunk function itself, FUNCTION is the decl for
+ the target function. DELTA is an immediate constant offset to be
+ added to THIS. If VCALL_OFFSET is nonzero, the word at
+ *(*this + vcall_offset) should be added to THIS. */
+ void (* output_mi_thunk) (FILE *file, tree thunk_decl,
+ HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset,
+ tree function_decl);
+
+ /* Determine whether output_mi_thunk would succeed. */
+ /* ??? Ideally, this hook would not exist, and success or failure
+ would be returned from output_mi_thunk directly. But there's
+ too much undo-able setup involved in invoking output_mi_thunk.
+ Could be fixed by making output_mi_thunk emit rtl instead of
+ text to the output file. */
+ bool (* can_output_mi_thunk) (const_tree thunk_decl, HOST_WIDE_INT delta,
+ HOST_WIDE_INT vcall_offset,
+ const_tree function_decl);
+
+ /* Output any boilerplate text needed at the beginning of a
+ translation unit. */
+ void (*file_start) (void);
+
+ /* Output any boilerplate text needed at the end of a
+ translation unit. */
+ void (*file_end) (void);
+
+ /* Output an assembler pseudo-op to declare a library function name
+ external. */
+ void (*external_libcall) (rtx);
+
+ /* Output an assembler directive to mark decl live. This instructs
+ linker to not dead code strip this symbol. */
+ void (*mark_decl_preserved) (const char *);
+
+ /* Output a record of the command line switches that have been passed. */
+ print_switch_fn_type record_gcc_switches;
+ /* The name of the section that the example ELF implementation of
+ record_gcc_switches will use to store the information. Target
+ specific versions of record_gcc_switches may or may not use
+ this information. */
+ const char * record_gcc_switches_section;
+
+ /* Output the definition of a section anchor. */
+ void (*output_anchor) (rtx);
+
+ /* Output a DTP-relative reference to a TLS symbol. */
+ void (*output_dwarf_dtprel) (FILE *file, int size, rtx x);
+
+ /* Some target machines need to postscan each insn after it is output. */
+ void (*final_postscan_insn) (FILE *, rtx, rtx *, int);
+
+ /* Emit the trampoline template. This hook may be NULL. */
+ void (*trampoline_template) (FILE *);
+
+HOOKSTRUCT (} asm_out;)
+
+HOOKSTRUCT (struct sched {)
+#endif /* 0 */
Index: target.h
===================================================================
--- target.h (revision 155367)
+++ target.h (working copy)
@@ -108,7 +108,13 @@ struct asm_int_op
};

/* The target structure. This holds all the backend hooks. */
+#define DEFHOOKPOD(NAME, DOC, TYPE, INIT) TYPE NAME;
+#define DEFHOOK(NAME, DOC, TYPE, PARAMS, INIT) TYPE (* NAME) PARAMS;
+#define HOOKSTRUCT(FRAGMENT) FRAGMENT

+#include "target.def"
+
+#if 0
struct gcc_target
{
/* Functions that output assembler for the target. */
@@ -141,6 +147,7 @@ struct gcc_target
this is only a placeholder for an omitted FDE. */
void (* unwind_label) (FILE *, tree, int, int);

+#endif /* 0 */
/* Output code that will emit a label to divide up the exception
table. */
void (* except_table_label) (FILE *);
Index: dwarf2out.c
===================================================================
--- dwarf2out.c (revision 155367)
+++ dwarf2out.c (working copy)
@@ -3457,8 +3457,8 @@ output_fde (dw_fde_ref fde, bool for_eh,
char l1[20], l2[20];
dw_cfi_ref cfi;

- targetm.asm_out.unwind_label (asm_out_file, fde->decl, for_eh,
- /* empty */ 0);
+ targetm.asm_out.emit_unwind_label (asm_out_file, fde->decl, for_eh,
+ /* empty */ 0);
targetm.asm_out.internal_label (asm_out_file, FDE_LABEL,
for_eh + j);
ASM_GENERATE_INTERNAL_LABEL (l1, FDE_AFTER_SIZE_LABEL, for_eh + j);
@@ -3651,8 +3651,8 @@ output_call_frame_info (int for_eh)
if ((fde_table[i].nothrow || fde_table[i].all_throwers_are_sibcalls)
&& !fde_table[i].uses_eh_lsda
&& ! DECL_WEAK (fde_table[i].decl))
- targetm.asm_out.unwind_label (asm_out_file, fde_table[i].decl,
- for_eh, /* empty */ 1);
+ targetm.asm_out.emit_unwind_label (asm_out_file, fde_table[i].decl,
+ for_eh, /* empty */ 1);

/* If we don't have any functions we'll want to unwind out of, don't
emit any EH unwind information. Note that if exceptions aren't
Index: gentarget.c
===================================================================
--- gentarget.c (revision 0)
+++ gentarget.c (revision 0)
@@ -0,0 +1,70 @@
+#include "bconfig.h"
+#include "system.h"
+#include <string.h>
+
+struct hook_desc { const char *doc, *type, *name, *param, *init; };
+static struct hook_desc hook_array[] = {
+#define DEFHOOKPOD(NAME, DOC, TYPE, INIT) \
+ { DOC, #TYPE, HOOK_PREFIX #NAME, 0, #INIT },
+#define DEFHOOK(NAME, DOC, TYPE, PARAMS, INIT) \
+ { DOC, #TYPE, HOOK_PREFIX #NAME, #PARAMS, #INIT },
+#include "target.def"
+#undef DEFHOOK
+};
+
+int
+main (int argc, char **argv)
+{
+ bool doc_p = false;
+ int i, j;
+
+ if (argc >= 2 && strcmp (argv[1], "-doc") == 0)
+ doc_p = true;
+ for (i = 0; i < (int) (sizeof hook_array / sizeof hook_array[0]); i++)
+ {
+ char *name = xstrdup (hook_array[i].name);
+ char *p;
+ const char *q, *e;
+
+ for (p = name; *p; p++)
+ *p = TOUPPER (*p);
+ if (doc_p)
+ {
+ const char *deftype;
+
+ if (!hook_array[i].doc)
+ continue;
+ if (*hook_array[i].doc == '*')
+ {
+ printf ("%s", hook_array[i].doc + 1);
+ continue;
+ }
+ deftype = hook_array[i].param ? "deftypefn" : "deftypevr";
+ printf ("@%s {Target Hook} {%s} %s",
+ deftype, hook_array[i].type, name);
+ if (hook_array[i].param)
+ {
+ /* Print the parameter list, with the parameter names
+ enclosed in @var{}. */
+ printf (" ");
+ for (q = hook_array[i].param; (e = strpbrk (q, " ,)"));
+ q = e + 1)
+ if (*e == ' ')
+ printf ("%.*s", e - q + 1, q);
+ else
+ printf ("@var{%.*s}%c", e - q, q, *e);
+ }
+ printf ("\n");
+ for (j = i + 1;
+ j < (int) (sizeof hook_array / sizeof hook_array[0])
+ && hook_array[j].doc == 0; j++)
+ printf ("@%sx {Target Hook} {%s} %s\n",
+ deftype, hook_array[i].type, name);
+ printf ("%s\n@end %s\n\n", hook_array[i].doc, deftype);
+ }
+ else
+ printf ("#ifndef %s\n#define %s %s\n#endif\n",
+ name, name, hook_array[i].init);
+ }
+ return 0;
+}
Index: Makefile.in
===================================================================
--- Makefile.in (revision 155367)
+++ Makefile.in (working copy)
@@ -3714,6 +3714,7 @@ build/genpreds.o : genpreds.c $(RTL_BASE
coretypes.h $(GTM_H) errors.h gensupport.h $(OBSTACK_H)
build/genrecog.o : genrecog.c $(RTL_BASE_H) $(BCONFIG_H) $(SYSTEM_H) \
coretypes.h $(GTM_H) errors.h gensupport.h
+build/gentarget.o : gentarget.c target.def $(BCONFIG_H) $(SYSTEM_H)

# Compile the programs that generate insn-* from the machine description.
# They are compiled with $(COMPILER_FOR_BUILD), and associated libraries,
@@ -3738,6 +3739,7 @@ build/gengenrtl$(build_exeext) : $(BUILD
build/genmodes$(build_exeext) : $(BUILD_ERRORS)
build/gengtype$(build_exeext) : build/gengtype-lex.o build/gengtype-parse.o \
$(BUILD_ERRORS)
+build/gentarget$(build_exeext) : $(BUILD_ERRORS)

# Generated source files for gengtype.
gengtype-lex.c : gengtype-lex.l

RE: Approval as AVR maintainer

2009-12-23T14:30:00Z

> -----Original Message-----
> From: Andrew Hutchinson [mailto:andrewhutchinson@...]
> Sent: Wednesday, December 23, 2009 3:25 PM
> To: Denis Chertykov; Anatoly Sokolov; GCC Development;
> Weddington, Eric
> Subject: Approval as AVR maintainer
>
> How does one get to be maintainer of port?
>
> Specifically AVR port - so that I do not need to get approval
> to commit
> changes. The time it takes now is rather longer than getting
> approval on
> other parts of GCC.

AFAIK, you ask the current maintainers of the AVR port, Denis and Anatoly, which you have just done so.

I haven't asked yet, but I'm also interested.

Approval as AVR maintainer

2009-12-23T14:24:58Z

How does one get to be maintainer of port?

Specifically AVR port - so that I do not need to get approval to commit
changes. The time it takes now is rather longer than getting approval on
other parts of GCC.

The process does not seem to be written down anywhere - but I am sure
someone will correct me if I am wrong.

Seasonal Greetings

Andy

tree check: expected SSA_NAME, have var_decl

2009-12-23T14:19:29Z

Hi,

After the tree-loop pass, I need to perform some analysis on the loop
and insert a "gimple function call statement" before the loop body.
The function call looks like,

foo(a, 1, 1); for a loop that looks like,

for (i = 0; i < 20; i ++) {
a[i]++;
}

When compiled with -O2, after the tree loop init, the loops have SSA
names for variables. Based on the analysis I do on the loop, I get a
TREE_NODE for the variable 'a', and two integer_one_node s.
I have trouble constructing the gimple_call_statement and adding it
before the loop_body. I am running into 'expected ssa_name have
var_decl' error. I am not sure I can use make_ssa_name for the
TREE_NODE of variable 'a' since I am yet to build a gimple_stmt that
will contain this variable.

How could I insert a call statement after a loop analysis ?

Thanks,
Aravinda

Re: Which optimizer should remove redundant subreg of sign_extension?

2009-12-23T12:22:41Z

Paolo Bonzini wrote:
>
> I think that if you add the simplification to simplify-rtx.c's
> simplify_subreg, combine should pick it up automagically.
>
> Paolo
>

There we have it! There is apparently already this optimization
performed - so I will have to dig further into why it does not a happen.

simplify_subreg()
<snip>
/* If we're requesting the lowpart of a zero or sign extension,
there are three possibilities. If the outermode is the same
as the origmode, we can omit both the extension and the subreg.
If the outermode is not larger than the origmode, we can apply
the truncation without the extension. Finally, if the outermode
is larger than the origmode, but both are integer modes, we
can just extend to the appropriate mode. */

Re: Unnecessary PRE optimization

2009-12-23T11:41:15Z

Similar situation happens in non loop context as well. PRE commoned
address computation without knowing the existence of advanced
addressing mode, which result in unnecessary address computation
instruction. The forward substitution code makes local heuristics and
looks at each use individually -- it does not know if the propagation
will happen for all uses and therefore exposes DCE opportunity -- so a
precise cost estimation is not available. Even so, for such cases, a
simple change of 'gain > 0' into 'gain >= 0' in
should_replace_address_p can do the job.

For LIM case discussed in this thread, it is trickier to estimate the
cost of forward substitution without knowing the register pressure --
forward prop MAY increase the live range of the propagated value
(RHS), even though in this case it does not, and it actually shrinks
the LR of the LHS temps, thus reducing register pressure overall. I
have submitted a live range shrink (LRS) patch a while back, but it
was not accepted. This address computation propagation can be easily
implemented in the LPS pass with precise knowledge of the change of
register pressure.

In general it will be tricky for latter passes to clean up the messes.
The fundamental problem is that the address computation is exposed to
PRE prematurely (for a given target ) at GIMPLE level. In this case,
if the INDIRECT_REFs are expressed as MEM_REFs, such problem might be
avoided. A similar issue (for ARM) is reported in bug 40956.

Thanks,

David

On Wed, Dec 23, 2009 at 10:06 AM, Paolo Bonzini <bonzini@...> wrote:

>
> On 12/23/2009 06:47 PM, H.J. Lu wrote:
>>
>> On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzini<bonzini@...> wrote:
>>>
>>> On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
>>>>
>>>> It seems that just commenting out this check in fwprop.c should work.
>>>
>>> Yes, but it would pessimize x86.
>>>
>>
>> Is there a bug open for x86? Can't we make it target dependent, something
>> like
>>
>> /* Do not propagate loop invariant definitions inside the loop. */
>> if (targetm.foobar
>> && DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father)
>> return;
>
> I'll open a bug. The solution is to actually understand what the address costs are on x86 (apparently it's not true that the more complex addressing modes are always better, probably because of instruction sizes), not to add a target macro.
>
> Paolo

Re: Unnecessary PRE optimization

2009-12-23T10:28:52Z

On Wed, Dec 23, 2009 at 10:06 AM, Paolo Bonzini <bonzini@...> wrote:

> On 12/23/2009 06:47 PM, H.J. Lu wrote:
>>
>> On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzini<bonzini@...> wrote:
>>>
>>> On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
>>>>
>>>> It seems that just commenting out this check in fwprop.c should work.
>>>
>>> Yes, but it would pessimize x86.
>>>
>>
>> Is there a bug open for x86? Can't we make it target dependent, something
>> like
>>
>> /* Do not propagate loop invariant definitions inside the loop. */
>> if (targetm.foobar
>> && DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father)
>> return;
>
> I'll open a bug. The solution is to actually understand what the address
> costs are on x86 (apparently it's not true that the more complex addressing
> modes are always better, probably because of instruction sizes), not to add
> a target macro.
>

I will ask around to see if there are any guild lines for this
after the bug is open.

Thanks.

--
H.J.

Re: Unnecessary PRE optimization

2009-12-23T10:06:31Z

On 12/23/2009 06:47 PM, H.J. Lu wrote:

> On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzini<bonzini@...> wrote:
>> On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
>>>
>>> It seems that just commenting out this check in fwprop.c should work.
>>
>> Yes, but it would pessimize x86.
>>
>
> Is there a bug open for x86? Can't we make it target dependent, something
> like
>
> /* Do not propagate loop invariant definitions inside the loop. */
> if (targetm.foobar
> && DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father)
> return;

I'll open a bug. The solution is to actually understand what the
address costs are on x86 (apparently it's not true that the more complex
addressing modes are always better, probably because of instruction
sizes), not to add a target macro.

Paolo

Re: Unnecessary PRE optimization

2009-12-23T09:47:46Z

On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzini <bonzini@...> wrote:
> On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
>>
>> It seems that just commenting out this check in fwprop.c should work.
>
> Yes, but it would pessimize x86.
>

Is there a bug open for x86? Can't we make it target dependent, something
like

/* Do not propagate loop invariant definitions inside the loop. */
if (targetm.foobar
&& DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father)
return;

--
H.J.

Re: How should I prototype cpp_define in target patch?

2009-12-23T09:42:36Z

Doh!

Joseph S. Myers wrote:

> On Wed, 23 Dec 2009, Andrew Hutchinson wrote:
>
>
>> builtin_define_std
>> cpp_define
>>
>> Both from c-cppbuiltin.c. These have no prototypes defined in gcc.
>>
>
> They do have prototypes, in c-common.h and cpplib.h.
>
>

Re: Unnecessary PRE optimization

2009-12-23T08:41:19Z

On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
> It seems that just commenting out this check in fwprop.c should work.

Yes, but it would pessimize x86.

Paolo

Re: Unnecessary PRE optimization

2009-12-23T08:02:44Z

On Wed, 2009-12-23 at 16:00 +0100, Paolo Bonzini wrote:
> On 12/23/2009 03:27 PM, Bingfeng Mei wrote:
> > Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
> > this should be fixed? Or it requires extra patch?
>
> No, if TARGET_ADDRESS_COST was fixed for x86 (and of course defined
> properly for your target), we could fix this very easily.

This problem appears to affect the ARM port as well - I can see this
being useful for the ARM port and might force us to look at
TARGET_ADDRESS_COST a little more carefully - so if you're happy to post
the fwprop patch I'm happy to test for performance on the ARM and look
at ADDRESS_COST carefully on the ARM.

cheers
Ramana
>
> Paolo

Re: How should I prototype cpp_define in target patch?

2009-12-23T07:46:45Z

On Wed, 23 Dec 2009, Andrew Hutchinson wrote:

> builtin_define_std
> cpp_define
>
> Both from c-cppbuiltin.c. These have no prototypes defined in gcc.

They do have prototypes, in c-common.h and cpplib.h.

--
Joseph S. Myers
joseph@...

RE: Unnecessary PRE optimization

2009-12-23T07:19:09Z

It seems that just commenting out this check in fwprop.c should work.

/* Do not propagate loop invariant definitions inside the loop. */
/* if (DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father)
return;*/

Bingfeng

> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@...] On
> Behalf Of Paolo Bonzini
> Sent: 23 December 2009 15:01
> To: Bingfeng Mei
> Cc: Steven Bosscher; gcc@...; dberlin@...
> Subject: Re: Unnecessary PRE optimization
>
> On 12/23/2009 03:27 PM, Bingfeng Mei wrote:
> > Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
> > this should be fixed? Or it requires extra patch?
>
> No, if TARGET_ADDRESS_COST was fixed for x86 (and of course defined
> properly for your target), we could fix this very easily.
>
> Paolo
>
>

target hooks / plugins

2009-12-23T07:12:56Z

Target hooks would often be interesting for plugins to modify. And
some proposed new plugin callbacks would also be interesting to have as
target hooks. Therefore, I would like target hooks to become writeable
by plugins, and make it much easier to add new target hooks in the GCC
sources.

Right now, to make a new target hook, you have to add a new field in
target.h, define a new default in target-def.h, place the new macro
in exactly the right position there of the right initializer macro,
describe the new hook in tm.texi, and if you need a new function with
a bunch of parameters returning a constant, you have to add this to
hooks.c .

I would like to be able to do all this by adding a single entry in a
new definition file; and the information should also be usable by
plugin sources so that they can automatically make wrappers for all
function-type hooks.

Most of the ICI unroll_parameter_handler / graphite_parameter_handler
callbacks can the be made into target hooks.

Re: Unnecessary PRE optimization

2009-12-23T07:00:38Z

On 12/23/2009 03:27 PM, Bingfeng Mei wrote:
> Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
> this should be fixed? Or it requires extra patch?

No, if TARGET_ADDRESS_COST was fixed for x86 (and of course defined
properly for your target), we could fix this very easily.

Paolo

Re: Preserving order of variable declarations

2009-12-23T06:57:17Z

On Tue, Dec 22, 2009 at 11:47, Aravinda <aravindakidambi@...> wrote:

> Is this is the only way it can be done ? Or can I have
> (non-temporary)variables inserted whos order can be preserved always ?

Not really, the compiler will reorder variables in the stack in almost
arbitrary ways. Wrapping them in structs is the safest approach.

Diego.

RE: Unnecessary PRE optimization

2009-12-23T06:27:15Z

Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
this should be fixed? Or it requires extra patch?

Bingfeng

> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@...] On
> Behalf Of Paolo Bonzini
> Sent: 23 December 2009 13:28
> To: Steven Bosscher
> Cc: Bingfeng Mei; gcc@...; dberlin@...
> Subject: Re: Unnecessary PRE optimization
>
> On 12/23/2009 01:01 PM, Steven Bosscher wrote:
> > On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng
> Mei<bmei@...> wrote:
> >> Hello,
> >> I encounter an issue with PRE optimization, which created worse
> >
> > Is this at -O2 or -O3?
>
> I think this could be fixed if fwprop propagated addresses
> into loops;
> it doesn't because it made performance worse on x86. The
> real reason is
> "address_cost on x86 sucks and nobody knows how to fix it
> exactly", but
> the performance hit was bad enough that we (Steven Bosscher and I)
> decided to put that hack into fwprop.
>
> Paolo
>
>

Re: Unnecessary PRE optimization

2009-12-23T06:09:54Z

On 12/23/2009 03:05 PM, Joern Rennecke wrote:
>
> So if this is only useful for a limited set of targets, why isn't it
> controlled by an option or a target hook so that it is only turned on
> on the targets where it is deemed to make sense overall?

Well, this optimization is basically the opposite of loop-invariant
motion, so there is some merit in not doing it: you could also tweak
loop-invariant motion to not hoist unnecessarily (and increase register
pressure unnecessarily) instead of relying on fwprop undoing it. Indeed
in trunk loop-invariant motion is not hoisting cheap addresses anymore.
Bingfeng is seeing the problem because in his case PRE is doing the
hoisting rather than LIM.

Paolo

Re: Unnecessary PRE optimization

2009-12-23T06:05:54Z

Quoting Paolo Bonzini <bonzini@...>:

> On 12/23/2009 01:01 PM, Steven Bosscher wrote:
>> On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei<bmei@...> wrote:
>>> Hello,
>>> I encounter an issue with PRE optimization, which created worse
>>
>> Is this at -O2 or -O3?
>
> I think this could be fixed if fwprop propagated addresses into loops;
> it doesn't because it made performance worse on x86. The real reason
> is "address_cost on x86 sucks and nobody knows how to fix it exactly",

And nobody has bothered to put in a bug report into bugzilla to describe
what they see malfunctioning... or if they did, it doesn't mention
address_cost.

> but the performance hit was bad enough that we (Steven Bosscher and I)
> decided to put that hack into fwprop.

So if this is only useful for a limited set of targets, why isn't it
controlled by an option or a target hook so that it is only turned on
on the targets where it is deemed to make sense overall?

Re: Unnecessary PRE optimization

2009-12-23T05:28:06Z

On 12/23/2009 01:01 PM, Steven Bosscher wrote:
> On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei<bmei@...> wrote:
>> Hello,
>> I encounter an issue with PRE optimization, which created worse
>
> Is this at -O2 or -O3?

I think this could be fixed if fwprop propagated addresses into loops;
it doesn't because it made performance worse on x86. The real reason is
"address_cost on x86 sucks and nobody knows how to fix it exactly", but
the performance hit was bad enough that we (Steven Bosscher and I)
decided to put that hack into fwprop.

Paolo

How should I prototype cpp_define in target patch?

2009-12-23T05:05:37Z

I want to post patch for

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42457

The code moved out to -c.c file ALREADY uses:

builtin_define_std
cpp_define

Both from c-cppbuiltin.c. These have no prototypes defined in gcc.

So of course there are warnings emitted.

Is this OK?
Should I locally define prototypes?
Something else?

Andy

RE: Unnecessary PRE optimization

2009-12-23T04:03:09Z

-O2

> -----Original Message-----
> From: Steven Bosscher [mailto:stevenb.gcc@...]
> Sent: 23 December 2009 12:01
> To: Bingfeng Mei
> Cc: gcc@...; dberlin@...
> Subject: Re: Unnecessary PRE optimization
>
> On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei
> <bmei@...> wrote:
> > Hello,
> > I encounter an issue with PRE optimization, which created worse
>
> Is this at -O2 or -O3?
>
> Ciao!
> Steven
>
>

Re: Unnecessary PRE optimization

2009-12-23T04:01:17Z

On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei <bmei@...> wrote:
> Hello,
> I encounter an issue with PRE optimization, which created worse

Is this at -O2 or -O3?

Ciao!
Steven

Unnecessary PRE optimization

2009-12-23T03:49:55Z

Hello,
I encounter an issue with PRE optimization, which created worse
code than no optimization.

This the test function:

void foo(int *data, int *m_v4w, int num)
{
int i;
int m0;
for( i=0; i<num; i++ )
{
int *data1 = (data[i] - 2);
int *data2 = data[i];
int tmp0, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7;
int d0, d1, d2, d3;

d0 = data1[0];
d1 = data2[0];
d2 = data1[1];
d3 = data2[1];

tmp0 = m_v4w[0];
tmp1 = m_v4w[2];
tmp2 = m_v4w[4];
tmp3 = m_v4w[6];
tmp4 = m_v4w[8];
tmp5 = m_v4w[10];
tmp6 = m_v4w[12];
tmp7 = m_v4w[14];

m0 = tmp0 * d0;
m0 += tmp1 * d0;
m0 += tmp2 * d1;
m0 += tmp3 * d1;
m0 += tmp4 * d2;
m0 += tmp5 * d2;
m0 += tmp6 * d3;
m0 += tmp7 * d3;

data2[0] = m0;
}
}

The following is the code generated for our processor (easy to understand).
PRE pass moves address expression (reg + constant offset) out of loop.
It increases both size and cycle unnecessarily since our architecture support
reg + constant offset addressing mode. It is even worse in bigger loops.
Too many registers cause spill in register allocation and performance suffers
further. This happens on both 4.4 and TRUNK versions. I also tested on x86,
which is the same.

gcc_compiled.:
.section .text, "axU"
.align 8
.global foo
.type foo,@function
foo:
cmplew p0, r2, zr
sbpt p0.0, [link]
addw r9, r1, #0x08 : addw r8, r1, #0x10
addw r7, r1, #0x18 : addw r6, r1, #0x20
addw r5, r1, #0x28 : addw r4, r1, #0x30
addw r3, r1, #0x38
.L3:
loop r2,.L6
ldw r10, [r0], #4! : ldw r11, [r1]
ldw r14, [r9] : ldw r22, [r7]
ldw r15, [r8] : ldw r21, [r5]
ldw r20, [r3] : ldw r13, [r6]
ldw r12, [r4]
ldw r19, [r10]
ldw r18, [r10, #-2] : ldw r17, [r10, #2]
ldw r16, [r10, #4] : addw r14, r14, r11
addw r15, r22, r15 : addw r13, r21, r13
addw r12, r20, r12
mulw r15, r15, r19
mulw r14, r14, r18 : mulw r13, r13, r17
mulw r12, r12, r16
addw r11, r15, r14
addw r11, r11, r13
addw r11, r11, r12
.L6:
stw r11, [r10]
.L7:
sbl [link]
.size foo,.-foo

The following is assembly code generated with -fno-tree-pre option.
foo:
cmplew p0, r2, zr
sbpt p0.0, [link]
.L3:
loop r2,.L6
ldw r3, [r0], #4! : ldw r4, [r1]
ldw r7, [r1, #8] : ldw r15, [r1, #24]
ldw r8, [r1, #16] : ldw r14, [r1, #40]
ldw r13, [r1, #56] : ldw r6, [r1, #32]
ldw r5, [r1, #48]
ldw r12, [r3]
ldw r11, [r3, #-2] : ldw r10, [r3, #2]
ldw r9, [r3, #4] : addw r7, r7, r4
addw r8, r15, r8 : addw r6, r14, r6
addw r5, r13, r5
mulw r8, r8, r12
mulw r7, r7, r11 : mulw r6, r6, r10
mulw r5, r5, r9
addw r4, r8, r7
addw r4, r4, r6
addw r4, r4, r5
.L6:
stw r4, [r3]
.L7:
sbl [link]
.size foo,.-foo

Re: Question on PR36873

2009-12-23T02:13:21Z

On 12/23/2009 06:12 PM, Dave Korn wrote:

> Jie Zhang wrote:
>
>> typedef unsigned short u16;
>> typedef unsigned int u32;
>>
>> u32 a(volatile u16* off) {
>> return *off;
>> }
>
>> mingw32-gcc-4.3.0.exe -c -O2 -fomit-frame-pointer -mtune=core2 test.c
>>
>> it produces:
>> 00000000<_a>:
>> 0: 8b 44 24 04 mov 0x4(%esp),%eax
>> 4: 0f b7 00 movzwl (%eax),%eax
>> 7: 0f b7 c0 movzwl %ax,%eax<== The redundant insn
>> a: c3 ret
>
> How does it look at the RTL level? I wonder if this situation is similar to
> the one being discussed in the other current thread "Which optimizer should
> remove redundant subreg of sign_extension?"
>

With my native GCC on Debian AMD64 unstable, in t.c.128r.expand:

(insn 6 5 7 3 t.c:5 (set (reg:HI 58 [ D.1595 ])
(mem/v:HI (reg/v/f:DI 60 [ off ]) [2 S2 A16])) -1 (nil))

(insn 7 6 8 3 t.c:5 (set (reg:SI 61)
(zero_extend:SI (reg:HI 58 [ D.1595 ]))) -1 (nil))

In t.c.201r.shorten:

(insn:TI 6 3 7 t.c:5 (set (reg:HI 0 ax [orig:58 D.1595 ] [58])
(mem/v:HI (reg/v/f:DI 5 di [orig:60 off ] [60]) [2 S2 A16])) 53
{*movhi_1} (expr_list:REG_DEAD (reg/v/f:DI 5 di [orig:60 off ] [60])
(nil)))

(insn:TI 7 6 18 t.c:5 (set (reg:SI 0 ax [orig:61 D.1595 ] [61])
(zero_extend:SI (reg:HI 0 ax [orig:58 D.1595 ] [58]))) 114
{*zero_extendhisi2_movzwl} (nil))

There is a volatile flag for mem operand. If there is no such flag, I
think one of RTL passes might combine them. It looks similar with the
issue in the thread you mentioned. But the cause is different.

Regards,
Jie

Re: Question on PR36873

2009-12-23T02:12:28Z

Jie Zhang wrote:

> typedef unsigned short u16;
> typedef unsigned int u32;
>
> u32 a(volatile u16* off) {
> return *off;
> }

> mingw32-gcc-4.3.0.exe -c -O2 -fomit-frame-pointer -mtune=core2 test.c
>
> it produces:
> 00000000 <_a>:
> 0: 8b 44 24 04 mov 0x4(%esp),%eax
> 4: 0f b7 00 movzwl (%eax),%eax
> 7: 0f b7 c0 movzwl %ax,%eax <== The redundant insn
> a: c3 ret

How does it look at the RTL level? I wonder if this situation is similar to
the one being discussed in the other current thread "Which optimizer should
remove redundant subreg of sign_extension?"

cheers,
DaveK

Re: How to implement pattens with more that 30 alternatives

2009-12-23T01:56:24Z

On Wed, 2009-12-23 at 10:11 +0530, Mohamed Shafi wrote:

> 2009/12/22 Richard Earnshaw <rearnsha@...>:
> >
> > On Mon, 2009-12-21 at 18:44 +0000, Paul Brook wrote:
> >> > > > I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of
> >> > > > scheduling framework i have to write the move patterns with more
> >> > > > clarity, so that i could control the scheduling with the help of
> >> > > > attributes. Re-writting the pattern resulted in movsi pattern with 41
> >> > > > alternatives :(
> >> > >
> >> > > Use rtl expressions instead of alternatives. e.g. arm.md:arith_shiftsi
> >> >
> >> > Or use the more modern iterators approach.
> >>
> >> Aren't iterators for generating multiple insns (e.g. movsi and movdi) from the
> >> same pattern, whereas in this case we have a single insn that needs to accept
> >> many different operand combinartions?
> >
> > Yes, but that is often better, I suspect, than having too fancy a
> > pattern that breaks the optimization simplifications that genrecog does.
> >
> > Note that the attributes that were requested could be made part of the
> > iterator as well, using a mode_attribute.
> >
> I can't find a back-end that does this. Can you show me a example?

I think the mips port is currently the most comprehensive example for
use of iterators.

R.

Re: Which optimizer should remove redundant subreg of sign_extension?

2009-12-23T01:22:24Z

On 12/22/2009 07:24 PM, Jeff Law wrote:

> On 12/22/09 11:16, Andrew Hutchinson wrote:
>> I came across this RTL on AVR in combine dump (part of va-arg-9.c test)
>>
>> (set (reg:QI 25 r25 [+1 ])
>> (subreg:QI (sign_extend:HI (reg:QI 49)) 1))
>>
>> The sign extension is completely redundant - the upper part of
>> register is not used elsewhere
>> - but the RTL remains unchanged through all the optimizers and
>> sign_extension appears in final code.
>>
>> Which RTL optimisation should be taking care of this? Propagation?
>> It would help me look in the right place to understand and perhaps fix
>> issue.
>>
>> I suspect the presence of hard register is why it does not get
>> removed. (the hard register is the function return value)
> I'd look at combine, though I think it's more concerned with determining
> that an extension is redundant because the bits already have the proper
> value rather than the bits not being used later. It might be the case
> that you can extend what's already in combine to do what you want.

I think that if you add the simplification to simplify-rtx.c's
simplify_subreg, combine should pick it up automagically.

Paolo

Re: Question on PR36873

2009-12-23T01:21:19Z

On 12/23/2009 02:43 PM, Jie Zhang wrote:
> Hi,
>
> We just got a similar problem on Blackfin GCC recently. Let me take the
> test code from the bug as an example:
>
I reduce the test case to a simpler one:

$ cat foo.c
unsigned int
foo (volatile unsigned short *p)
{
return *p;
}

I the tree dump "foo.c.126t.optimized", GCC refused to eliminate D.1256
because the first statement contains a volatile operand:

D.1256 ={v} *p;
return (unsigned int) D.1256;

I'm not familiar with the trees. Is it possible to replace D.1256 and
have something like below?

return (unsigned int) {v} *p;

I experiment a little. It seems {v} will be lost in SSA name replacing
during out of SSA transform. Can anyone pointed me if it's possible to
do the replace but still keep {v}? Or I should find another way to do
that? Or it's wrong to do this optimization?

Thanks,

Jie

Re: CSE & compare/branch template problem

2009-12-23T01:20:06Z

On 12/21/2009 08:10 PM, Richard Henderson wrote:

> (define_insn_and_split "*cmp"
> [(set (match_operand:SI 0 "register_operand" "=r")
> (lt:SI (match_operand:SI 1 "register_operand" "r")
> (match_operand:SI 2 "register_operand" "r")))]
> ""
> "cmp %0,%1,%2\;andi $0,$0,1"
> ""
> [(set (match_dup 0)
> (unspec:SI [(match_dup 1) (match_dup 2)] UNSPEC_CMP))
> (set (match_dup 0) (and:SI (match_dup 0) (const_int 1)))]
> "")

It's actually the MSB that is affected, and the entire register is set
to zero if a == b. Basically cmp/cmpu prepare rD so that a signed
compare-with-zero-and-branch will do the requested conditional branch.

So, branches are easy, but cstores are tricky. Something like this
should work; indeed you do not need any CC mode:

;; cbranch expander, possibly use cmp/cmpu to make operand 0 into a
;; signed comparison with zero
(define_expand "cbranchsi4"
[(set (pc)
(if_then_else
(match_operator 0 "ordered_comparison_operator"
[(match_operand:SI 1 "register_operand" "")
(match_operand:SI 2 "register_operand_or_0" "")])
(label_ref (match_operand 3 ""))
(pc)))]
"enum rtx_code signed =
signed_condition (GET_CODE (operands[0]));
if (operands[2] != const0_rtx || signed != GET_CODE (operands[0]))
{
rtx reg = gen_reg_rtx (SImode);
if (signed != GET_CODE (operands[0]))
emit_insn (gen_cmpusi (reg, operands[1], operands[2]));
else
emit_insn (gen_cmpsi (reg, operands[1], operands[2]));

operands[1] = reg;
operands[2] = const0_rtx;
operands[0] = gen_rtx_fmt_ee (signed, SImode, reg, const0_rtx);
}")

;; branch instructions do a signed comparison with 0 (needs
;; a predicate signed_comparison_operator), you could also
;; write a pattern for indirect conditional branches
(define_insn "*branch"
[(set (pc)
(if_then_else
(match_operator 0 "signed_comparison_operator"
[(match_operand:SI 1 "register_operand" "")
(const_int 0)])
(label_ref (match_operand 2 ""))
(pc)))]
""
"b%0i %1,%2"
"")

;; unspecs for cmp/cmpu
(define_insn "cmpsi"
[(set (match_operand:SI 0 "register_operand" "=r")
(unspec
[(match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r")] UNSPEC_CMP))]
""
"cmp %0,%1,%2"
"")

(define_insn "cmpusi"
[(set (match_operand:SI 0 "register_operand" "=r")
(unspec
[(match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r")] UNSPEC_CMPU))]
""
"cmp %0,%1,%2"
"")

;; these are used for cstore tricks when the old contents of rD are
;; significant
(define_insn "*cmpsi4"
[(set (match_operand:SI 0 "register_operand" "+r")
(unspec
[(match_dup 0)
(match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r")] UNSPEC_CMP))]
""
"cmp %0,%1,%2"
"")

(define_insn "*cmpusi4"
[(set (match_operand:SI 0 "register_operand" "+r")
(unspec
[(match_dup 0)
(match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r")] UNSPEC_CMPU))]
""
"cmp %0,%1,%2"
"")

;; some cstore patterns: cstoresi4 should canonicalize lt/ltu to gt/gtu,
;; as should CANONICALIZE_COMPARISON.
;;
;; common code takes care of ge/geu/le/leu as long as the rtx_costs say
;; it's profitable. Same for a != b for nonzero b.
;;
;; ...
;; if (GET_CODE (operands[1]) == LT || GET_CODE (operands[1]) == LTU)
;; {
;; operands[1] =
;; gen_rtx_fmt_ee (swap_condition (GET_CODE (operands[1])),
;; SImode, operands[3], operands[2]);
;; operands[2] = XEXP (operands[1], 0);
;; operands[3] = XEXP (operands[1], 1);
;; }
;; else if (GET_CODE (operands[1]) == NE && operands[3] != const0_rtx)
;; FAIL;
;;

;; preset rD to 1 to implement a == b
(define_insn_and_split "eqsi3"
[(set (match_operand:SI 0 "register_operand" "=&r")
(eq:SI (match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r")))]
""
""
""
[(set (match_dup 0) (const_int 1))
(set (match_dup 0) (unspec:SI [(match_dup 0)
(match_dup 1) (match_dup 2)]
UNSPEC_CMP))
(set (match_dup 0) (and:SI (match_dup 0) (const_int 1))]
"")

;; use a GTU 0 to implement a != 0. but cmpu does not accept immediates
(define_insn_and_split "nesi3"
[(set (match_operand:SI 0 "register_operand" "=&r")
(ne:SI (match_operand:SI 1 "register_operand" "r")
(const_int 0)))]
""
""
""
[(set (match_dup 0) (const_int 0))
(set (match_dup 0) (unspec:SI [(match_dup 1) (match_dup 0)]
UNSPEC_CMPU))
(set (match_dup 0) (lshiftrt:SI (match_dup 0) (const_int 31))]
"")

;; these are easy at least :-)
(define_insn_and_split "gtsi3"
[(set (match_operand:SI 0 "register_operand" "=r")
(gt:SI (match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r")))]
""
""
""
[(set (match_dup 0) (unspec:SI [(const_int 0)
(match_dup 1) (match_dup 2)]
UNSPEC_CMP))
(set (match_dup 0) (lshiftrt:SI (match_dup 0) (const_int 31))]
"")

(define_insn_and_split "gtusi3"
[(set (match_operand:SI 0 "register_operand" "=r")
(gtu:SI (match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r")))]
""
""
""
[(set (match_dup 0) (unspec:SI [(const_int 0)
(match_dup 1) (match_dup 2)]
UNSPEC_CMPU))
(set (match_dup 0) (lshiftrt:SI (match_dup 0) (const_int 31))]
"")

;; some sample combiner patterns

(define_insn_and_split "*negnesi3"
[(set (match_operand:SI 0 "register_operand" "=&r")
(neg:SI
(ne:SI (match_operand:SI 1 "register_operand" "r")
(const_int 0))))]
""
""
""
[(set (match_dup 0) (const_int 0))
(set (match_dup 0) (unspec:SI [(match_dup 1) (match_dup 0)]
UNSPEC_CMPU))
(set (match_dup 0) (ashiftrt:SI (match_dup 0) (const_int 31))]
"")

(define_insn_and_split "*neggtsi3"
[(set (match_operand:SI 0 "register_operand" "=r")
(neg:SI
(gt:SI (match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r"))))]
""
""
""
[(set (match_dup 0) (unspec:SI [(const_int 0)
(match_dup 1) (match_dup 2)]
UNSPEC_CMP))
(set (match_dup 0) (ashiftrt:SI (match_dup 0) (const_int 31))]
"")

(define_insn_and_split "*neggtusi3"
[(set (match_operand:SI 0 "register_operand" "=r")
(neg:SI
(gtu:SI (match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r"))))]
""
""
""
[(set (match_dup 0) (unspec:SI [(const_int 0)
(match_dup 1) (match_dup 2)]
UNSPEC_CMPU))
(set (match_dup 0) (ashiftrt:SI (match_dup 0) (const_int 31))]
"")

Paolo

Package hosting sites for MPC

2009-12-22T23:08:53Z

If anyone would like to obtain MPC from a pre-built package, there is a page
on the MPC website listing known providers for various OSes.

http://www.multiprecision.org/index.php?prog=mpc&page=packages

It's still missing several of our important platforms, including solaris,
aix and hpux. If you can convince your favorite package site (e.g.
blastwave.org or hpux.connect.org.uk) to offer binaries for these systems,
please do and notify the MPC mailing list (not me) about it here:

http://lists.gforge.inria.fr/mailman/listinfo/mpc-discuss

Thanks,
--Kaveh
--
Kaveh R. Ghazi

Question on PR36873

2009-12-22T22:43:23Z

Hi,

We just got a similar problem on Blackfin GCC recently. Let me take the
test code from the bug as an example:

typedef unsigned short u16;
typedef unsigned int u32;

u32 a(volatile u16* off) {
return *off;
}

u32 b(u16* off) {
return *off;
}

compiled with
mingw32-gcc-4.3.0.exe -c -O2 -fomit-frame-pointer -mtune=core2 test.c

it produces:
00000000 <_a>:
0: 8b 44 24 04 mov 0x4(%esp),%eax
4: 0f b7 00 movzwl (%eax),%eax
7: 0f b7 c0 movzwl %ax,%eax <== The redundant insn
a: c3 ret

00000010 <_b>:
10: 8b 44 24 04 mov 0x4(%esp),%eax
14: 0f b7 00 movzwl (%eax),%eax
17: c3 ret

I don't understand Richard's comment. What do we not optimize volatile
accesses in this test case. I know we cannot do many optimizations on
volatile accesses, but I think it's OK to remove the redundant insn in
this case. Could someone provide me a case in which we cannot remove it.

Thanks,
Jie

Re: How to implement pattens with more that 30 alternatives

2009-12-22T20:41:59Z

2009/12/22 Richard Earnshaw <rearnsha@...>:

>
> On Mon, 2009-12-21 at 18:44 +0000, Paul Brook wrote:
>> > > > I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of
>> > > > scheduling framework i have to write the move patterns with more
>> > > > clarity, so that i could control the scheduling with the help of
>> > > > attributes. Re-writting the pattern resulted in movsi pattern with 41
>> > > > alternatives :(
>> > >
>> > > Use rtl expressions instead of alternatives. e.g. arm.md:arith_shiftsi
>> >
>> > Or use the more modern iterators approach.
>>
>> Aren't iterators for generating multiple insns (e.g. movsi and movdi) from the
>> same pattern, whereas in this case we have a single insn that needs to accept
>> many different operand combinartions?
>
> Yes, but that is often better, I suspect, than having too fancy a
> pattern that breaks the optimization simplifications that genrecog does.
>
> Note that the attributes that were requested could be made part of the
> iterator as well, using a mode_attribute.
>

I can't find a back-end that does this. Can you show me a example?

Regards,
Shafi

gcc-4.4-20091222 is now available

2009-12-22T14:48:58Z

Snapshot gcc-4.4-20091222 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091222/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 155409

You'll find:

gcc-4.4-20091222.tar.bz2 Complete GCC (includes all of below)

gcc-core-4.4-20091222.tar.bz2 C front end and core compiler

gcc-ada-4.4-20091222.tar.bz2 Ada front end and runtime

gcc-fortran-4.4-20091222.tar.bz2 Fortran front end and runtime

gcc-g++-4.4-20091222.tar.bz2 C++ front end and runtime

gcc-java-4.4-20091222.tar.bz2 Java front end and runtime

gcc-objc-4.4-20091222.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20091222.tar.bz2 The GCC testsuite

Diffs from 4.4-20091215 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated and a message is sent to the gcc list. Please do not use
a snapshot before it has been announced that way.