Re: TODO_rebuild_alias and -O0
Richard Guenther skribis: > On Mon, Oct 8, 2012 at 6:04 PM, Ludovic Courtès > wrote: [...] >> So it looks like there’s additional state corresponding to these >> variables that needs updating? > > Ah, no, but I suppose TODO_update_address_taken doesn't really work at -O0 > so you need to fix that to do nothing at -O0. OK, thank you! Ludo’.
Re: TODO_rebuild_alias and -O0
On Mon, Oct 8, 2012 at 6:04 PM, Ludovic Courtès
wrote:
> Richard Guenther skribis:
>
>> On Mon, Oct 8, 2012 at 3:32 PM, Ludovic Courtès wrote:
>>> Richard Guenther skribis:
>>>
On Mon, Oct 8, 2012 at 1:42 PM, Ludovic Courtès wrote:
> Richard Guenther skribis:
>
>> On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès wrote:
>>> Richard Guenther skribis:
>>>
At -O0 no virtual operands are produced. TODO_rebuild_alias only
computes
points-to sets which are in itself not useful.
What do you want to achieve with TODO_rebuild_alias?
>>>
>>> I basically want to use ‘ptr_derefs_may_alias_p’ in this particular
>>> pass.
>>
>> That should work.
>
> It actually does, except that ‘ptr_derefs_may_alias_p’ returns true for
> two SSA names in cases like this:
>
> double *p, *q;
> p = malloc (123);
> q = malloc (234);
>
> (Where ‘malloc’ has the ‘malloc’ attribute.)
>
> For some reason, there’s no such false positive when using
> TODO_rebuild_alias.
Well, "that should work" means it works non-conservatively with
TODO_rebuild_alias, of course.
>>>
>>> Right. :-) So how can I get maximum accuracy, while avoid the assertion
>>> failure on -O0?
>>
>> You have to analyze the assert more. From the backtrace I cannot see
>> anything suspicious.
>
> The assert in ‘make_decl_rtl’ is:
>
> gcc_assert (TREE_CODE (decl) != VAR_DECL
> || TREE_STATIC (decl)
> || TREE_PUBLIC (decl)
> || DECL_EXTERNAL (decl)
> || DECL_REGISTER (decl));
>
> Upon inspection, ‘decl’ is VAR_DECL, but has all 4 flags above cleared.
>
> In my example source file, the assertion is hit here:
>
> numbers.c: In function ‘scm_c_make_polar’:
> numbers.c:8728:10: internal compiler error: in make_decl_rtl, at
> varasm.c:1163
>
> That line in numbers.c reads this:
>
> sincos (ang, &s, &c);
>
> And indeed, the dump of my pass (with -ftree-dump-all) reads this:
>
> ;; Function scm_c_make_polar (scm_c_make_polar)
>
> Now a gimple register: D.26884
> No longer having address taken: s
> No longer having address taken: c
>
>
> Symbols to be put in SSA form
>
> { s c D.26884 }
>
>
> Incremental SSA update started at block: 0
>
> Number of blocks in CFG: 8
> Number of blocks to update: 7 ( 88%)
>
> So it looks like there’s additional state corresponding to these
> variables that needs updating?
Ah, no, but I suppose TODO_update_address_taken doesn't really work at -O0
so you need to fix that to do nothing at -O0. Because s and c _do_ have their
address taken.
Richard.
> Thanks,
> Ludo’.
Re: TODO_rebuild_alias and -O0
Richard Guenther skribis:
> On Mon, Oct 8, 2012 at 3:32 PM, Ludovic Courtès wrote:
>> Richard Guenther skribis:
>>
>>> On Mon, Oct 8, 2012 at 1:42 PM, Ludovic Courtès wrote:
Richard Guenther skribis:
> On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès wrote:
>> Richard Guenther skribis:
>>
>>> At -O0 no virtual operands are produced. TODO_rebuild_alias only
>>> computes
>>> points-to sets which are in itself not useful.
>>>
>>> What do you want to achieve with TODO_rebuild_alias?
>>
>> I basically want to use ‘ptr_derefs_may_alias_p’ in this particular pass.
>
> That should work.
It actually does, except that ‘ptr_derefs_may_alias_p’ returns true for
two SSA names in cases like this:
double *p, *q;
p = malloc (123);
q = malloc (234);
(Where ‘malloc’ has the ‘malloc’ attribute.)
For some reason, there’s no such false positive when using
TODO_rebuild_alias.
>>>
>>> Well, "that should work" means it works non-conservatively with
>>> TODO_rebuild_alias, of course.
>>
>> Right. :-) So how can I get maximum accuracy, while avoid the assertion
>> failure on -O0?
>
> You have to analyze the assert more. From the backtrace I cannot see
> anything suspicious.
The assert in ‘make_decl_rtl’ is:
gcc_assert (TREE_CODE (decl) != VAR_DECL
|| TREE_STATIC (decl)
|| TREE_PUBLIC (decl)
|| DECL_EXTERNAL (decl)
|| DECL_REGISTER (decl));
Upon inspection, ‘decl’ is VAR_DECL, but has all 4 flags above cleared.
In my example source file, the assertion is hit here:
numbers.c: In function ‘scm_c_make_polar’:
numbers.c:8728:10: internal compiler error: in make_decl_rtl, at varasm.c:1163
That line in numbers.c reads this:
sincos (ang, &s, &c);
And indeed, the dump of my pass (with -ftree-dump-all) reads this:
;; Function scm_c_make_polar (scm_c_make_polar)
Now a gimple register: D.26884
No longer having address taken: s
No longer having address taken: c
Symbols to be put in SSA form
{ s c D.26884 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 8
Number of blocks to update: 7 ( 88%)
So it looks like there’s additional state corresponding to these
variables that needs updating?
Thanks,
Ludo’.
Re: TODO_rebuild_alias and -O0
On Mon, Oct 8, 2012 at 3:32 PM, Ludovic Courtès wrote: > Richard Guenther skribis: > >> On Mon, Oct 8, 2012 at 1:42 PM, Ludovic Courtès wrote: >>> Richard Guenther skribis: >>> On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès wrote: > Richard Guenther skribis: > >> At -O0 no virtual operands are produced. TODO_rebuild_alias only >> computes >> points-to sets which are in itself not useful. >> >> What do you want to achieve with TODO_rebuild_alias? > > I basically want to use ‘ptr_derefs_may_alias_p’ in this particular pass. That should work. >>> >>> It actually does, except that ‘ptr_derefs_may_alias_p’ returns true for >>> two SSA names in cases like this: >>> >>> double *p, *q; >>> p = malloc (123); >>> q = malloc (234); >>> >>> (Where ‘malloc’ has the ‘malloc’ attribute.) >>> >>> For some reason, there’s no such false positive when using >>> TODO_rebuild_alias. >> >> Well, "that should work" means it works non-conservatively with >> TODO_rebuild_alias, of course. > > Right. :-) So how can I get maximum accuracy, while avoid the assertion > failure on -O0? You have to analyze the assert more. From the backtrace I cannot see anything suspicious. > Thanks, > Ludo’.
Re: TODO_rebuild_alias and -O0
Richard Guenther skribis: > On Mon, Oct 8, 2012 at 1:42 PM, Ludovic Courtès wrote: >> Richard Guenther skribis: >> >>> On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès wrote: Richard Guenther skribis: > At -O0 no virtual operands are produced. TODO_rebuild_alias only computes > points-to sets which are in itself not useful. > > What do you want to achieve with TODO_rebuild_alias? I basically want to use ‘ptr_derefs_may_alias_p’ in this particular pass. >>> >>> That should work. >> >> It actually does, except that ‘ptr_derefs_may_alias_p’ returns true for >> two SSA names in cases like this: >> >> double *p, *q; >> p = malloc (123); >> q = malloc (234); >> >> (Where ‘malloc’ has the ‘malloc’ attribute.) >> >> For some reason, there’s no such false positive when using >> TODO_rebuild_alias. > > Well, "that should work" means it works non-conservatively with > TODO_rebuild_alias, of course. Right. :-) So how can I get maximum accuracy, while avoid the assertion failure on -O0? Thanks, Ludo’.
Re: TODO_rebuild_alias and -O0
On Mon, Oct 8, 2012 at 1:42 PM, Ludovic Courtès wrote: > Richard Guenther skribis: > >> On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès wrote: >>> Richard Guenther skribis: >>> At -O0 no virtual operands are produced. TODO_rebuild_alias only computes points-to sets which are in itself not useful. What do you want to achieve with TODO_rebuild_alias? >>> >>> I basically want to use ‘ptr_derefs_may_alias_p’ in this particular pass. >> >> That should work. > > It actually does, except that ‘ptr_derefs_may_alias_p’ returns true for > two SSA names in cases like this: > > double *p, *q; > p = malloc (123); > q = malloc (234); > > (Where ‘malloc’ has the ‘malloc’ attribute.) > > For some reason, there’s no such false positive when using TODO_rebuild_alias. Well, "that should work" means it works non-conservatively with TODO_rebuild_alias, of course. Richard. > Ludo’.
Re: TODO_rebuild_alias and -O0
Richard Guenther skribis: > On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès wrote: >> Richard Guenther skribis: >> >>> At -O0 no virtual operands are produced. TODO_rebuild_alias only computes >>> points-to sets which are in itself not useful. >>> >>> What do you want to achieve with TODO_rebuild_alias? >> >> I basically want to use ‘ptr_derefs_may_alias_p’ in this particular pass. > > That should work. It actually does, except that ‘ptr_derefs_may_alias_p’ returns true for two SSA names in cases like this: double *p, *q; p = malloc (123); q = malloc (234); (Where ‘malloc’ has the ‘malloc’ attribute.) For some reason, there’s no such false positive when using TODO_rebuild_alias. Ludo’.
Re: TODO_rebuild_alias and -O0
On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès wrote: > Richard Guenther skribis: > >> At -O0 no virtual operands are produced. TODO_rebuild_alias only computes >> points-to sets which are in itself not useful. >> >> What do you want to achieve with TODO_rebuild_alias? > > I basically want to use ‘ptr_derefs_may_alias_p’ in this particular pass. That should work. > Thanks, > Ludo’.
Re: TODO_rebuild_alias and -O0
Richard Guenther skribis: > At -O0 no virtual operands are produced. TODO_rebuild_alias only computes > points-to sets which are in itself not useful. > > What do you want to achieve with TODO_rebuild_alias? I basically want to use ‘ptr_derefs_may_alias_p’ in this particular pass. Thanks, Ludo’.
Re: TODO_rebuild_alias and -O0
On Mon, Oct 8, 2012 at 11:26 AM, Ludovic Courtès wrote: > Hello, > > Consider the attached plug-in, which adds a new dummy pass after the > “ssa” pass, with ‘TODO_rebuild_alias’ as its start flags: > > > > When compiling with -O0 a non-trivial file with that plug-in, one ends > up with: > > numbers.c:8728:10: internal compiler error: in make_decl_rtl, at > varasm.c:1163 > gcc: internal compiler error: Aborted (program cc1) > > and a backtrace like this: > > --8<---cut here---start->8--- > #6 0x0056bfa4 in fancy_abort (file=, line=1163, > function=0xc2a3f5 "make_decl_rtl") at ../../gcc-4.6.2/gcc/diagnostic.c:893 > #7 0x00853bae in make_decl_rtl (decl=0x7f3cfd0458c0) at > ../../gcc-4.6.2/gcc/varasm.c:1159 > #8 0x005bd485 in expand_expr_real_1 (exp=0x7f3cfd0458c0, > target=, > tmode=VOIDmode, modifier=EXPAND_WRITE, alt_rtl=) > at ../../gcc-4.6.2/gcc/expr.c:8462 > #9 0x005c83a8 in expand_expr (modifier=EXPAND_WRITE, mode=VOIDmode, > target=0x0, > exp=0x7f3cfd0458c0) at ../../gcc-4.6.2/gcc/expr.h:422 > #10 expand_assignment (nontemporal=0 '\000', from=0x7f3cfc967160, > to=0x7f3cfd0458c0) > at ../../gcc-4.6.2/gcc/expr.c:4422 > #11 expand_assignment (to=0x7f3cfd0458c0, from=0x7f3cfc967160, nontemporal=0 > '\000') > at ../../gcc-4.6.2/gcc/expr.c:4119 > #12 0x005350c8 in expand_gimple_stmt_1 (stmt=0x7f3cfd046460) > at ../../gcc-4.6.2/gcc/cfgexpand.c:1975 > #13 expand_gimple_stmt (stmt=0x7f3cfd046460) at > ../../gcc-4.6.2/gcc/cfgexpand.c:2084 > #14 0x00536218 in expand_gimple_basic_block (bb=0x7f3cfd047a90) > at ../../gcc-4.6.2/gcc/cfgexpand.c:3626 > #15 0x00539bbe in gimple_expand_cfg () at > ../../gcc-4.6.2/gcc/cfgexpand.c:4109 > #16 0x0068b589 in execute_one_pass (pass=0x10a3dc0) at > ../../gcc-4.6.2/gcc/passes.c:1556 > #17 0x0068b835 in execute_pass_list (pass=0x10a3dc0) at > ../../gcc-4.6.2/gcc/passes.c:1611 > #18 0x00757751 in tree_rest_of_compilation (fndecl=0x7f3cfdb03900) > at ../../gcc-4.6.2/gcc/tree-optimize.c:422 > #19 0x008978cf in cgraph_expand_function (node=0x7f3cfd2c8420) > at ../../gcc-4.6.2/gcc/cgraphunit.c:1576 > #20 0x0089975e in cgraph_output_in_order () at > ../../gcc-4.6.2/gcc/cgraphunit.c:1733 > #21 cgraph_optimize () at ../../gcc-4.6.2/gcc/cgraphunit.c:1894 > #22 0x0089992a in cgraph_finalize_compilation_unit () > at ../../gcc-4.6.2/gcc/cgraphunit.c:1096 > #23 0x004a3df5 in c_write_global_declarations () at > ../../gcc-4.6.2/gcc/c-decl.c:9871 > --8<---cut here---end--->8--- > > There’s no such problem when optimizations are turned on, though. > > Does it mean that extra work is needed at -O0 before one can use alias info? At -O0 no virtual operands are produced. TODO_rebuild_alias only computes points-to sets which are in itself not useful. What do you want to achieve with TODO_rebuild_alias? Richard. > Thanks, > Ludo’. >
TODO_rebuild_alias and -O0
Hello,
Consider the attached plug-in, which adds a new dummy pass after the
“ssa” pass, with ‘TODO_rebuild_alias’ as its start flags:
#include
#include
#include
#include
int plugin_is_GPL_compatible;
static unsigned int
my_pass (void)
{
return 0;
}
static struct opt_pass pass_dummy =
{
.type = GIMPLE_PASS,
.name = "my_pass",
.gate = NULL,
.execute = my_pass,
.todo_flags_start = TODO_rebuild_alias,
.properties_required = PROP_ssa
/* The rest is zeroed. */
};
int
plugin_init (struct plugin_name_args *plugin_info,
struct plugin_gcc_version *version)
{
struct register_pass_info pass_info2 =
{
.pass = &pass_dummy,
.reference_pass_name = "ssa",
.ref_pass_instance_number = 1,
.pos_op = PASS_POS_INSERT_AFTER
};
register_callback ("alias", PLUGIN_PASS_MANAGER_SETUP,
NULL, &pass_info2);
return 0;
}
/*
Local Variables:
compile-command: "gcc -shared -fPIC -Wall -I`gcc -print-file-name=plugin`/include -o alias.so alias.c"
End:
*/
When compiling with -O0 a non-trivial file with that plug-in, one ends
up with:
numbers.c:8728:10: internal compiler error: in make_decl_rtl, at varasm.c:1163
gcc: internal compiler error: Aborted (program cc1)
and a backtrace like this:
--8<---cut here---start->8---
#6 0x0056bfa4 in fancy_abort (file=, line=1163,
function=0xc2a3f5 "make_decl_rtl") at ../../gcc-4.6.2/gcc/diagnostic.c:893
#7 0x00853bae in make_decl_rtl (decl=0x7f3cfd0458c0) at
../../gcc-4.6.2/gcc/varasm.c:1159
#8 0x005bd485 in expand_expr_real_1 (exp=0x7f3cfd0458c0,
target=,
tmode=VOIDmode, modifier=EXPAND_WRITE, alt_rtl=)
at ../../gcc-4.6.2/gcc/expr.c:8462
#9 0x005c83a8 in expand_expr (modifier=EXPAND_WRITE, mode=VOIDmode,
target=0x0,
exp=0x7f3cfd0458c0) at ../../gcc-4.6.2/gcc/expr.h:422
#10 expand_assignment (nontemporal=0 '\000', from=0x7f3cfc967160,
to=0x7f3cfd0458c0)
at ../../gcc-4.6.2/gcc/expr.c:4422
#11 expand_assignment (to=0x7f3cfd0458c0, from=0x7f3cfc967160, nontemporal=0
'\000')
at ../../gcc-4.6.2/gcc/expr.c:4119
#12 0x005350c8 in expand_gimple_stmt_1 (stmt=0x7f3cfd046460)
at ../../gcc-4.6.2/gcc/cfgexpand.c:1975
#13 expand_gimple_stmt (stmt=0x7f3cfd046460) at
../../gcc-4.6.2/gcc/cfgexpand.c:2084
#14 0x00536218 in expand_gimple_basic_block (bb=0x7f3cfd047a90)
at ../../gcc-4.6.2/gcc/cfgexpand.c:3626
#15 0x00539bbe in gimple_expand_cfg () at
../../gcc-4.6.2/gcc/cfgexpand.c:4109
#16 0x0068b589 in execute_one_pass (pass=0x10a3dc0) at
../../gcc-4.6.2/gcc/passes.c:1556
#17 0x0068b835 in execute_pass_list (pass=0x10a3dc0) at
../../gcc-4.6.2/gcc/passes.c:1611
#18 0x00757751 in tree_rest_of_compilation (fndecl=0x7f3cfdb03900)
at ../../gcc-4.6.2/gcc/tree-optimize.c:422
#19 0x008978cf in cgraph_expand_function (node=0x7f3cfd2c8420)
at ../../gcc-4.6.2/gcc/cgraphunit.c:1576
#20 0x0089975e in cgraph_output_in_order () at
../../gcc-4.6.2/gcc/cgraphunit.c:1733
#21 cgraph_optimize () at ../../gcc-4.6.2/gcc/cgraphunit.c:1894
#22 0x0089992a in cgraph_finalize_compilation_unit ()
at ../../gcc-4.6.2/gcc/cgraphunit.c:1096
#23 0x004a3df5 in c_write_global_declarations () at
../../gcc-4.6.2/gcc/c-decl.c:9871
--8<---cut here---end--->8---
There’s no such problem when optimizations are turned on, though.
Does it mean that extra work is needed at -O0 before one can use alias info?
Thanks,
Ludo’.
