Re: TODO_rebuild_alias and -O0

[ludovic dot courtes at inria dot fr (Ludovic Courtès)]

Richard Guenther <richard.guenther@gmail.com> skribis:

> On Mon, Oct 8, 2012 at 3:32 PM, Ludovic CourtÃs <ludo@gnu.org> wrote:
>> Richard Guenther <richard.guenther@gmail.com> skribis:
>>
>>> On Mon, Oct 8, 2012 at 1:42 PM, Ludovic CourtÃs <ludo@gnu.org> wrote:
>>>> Richard Guenther <richard.guenther@gmail.com> skribis:
>>>>
>>>>> On Mon, Oct 8, 2012 at 11:58 AM, Ludovic CourtÃs <ludo@gnu.org> wrote:
>>>>>> Richard Guenther <richard.guenther@gmail.com> 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â.