QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

[sumanth]

Hi,
    I have a doubt regarding target macros ELIMINABLE_REGS and 
CAN_ELIMINATE.
    I defined eliminable regs as
    #define ELIMINABLE_REGS  { \
        {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} , \
        {FRAME_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM} , \
        {HARD_FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} }
   and CAN_ELIMINATE(FROM, TO) as if it has to replace 
FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM
   whenever !(frame_pointer_needed).

   But, my code generated is not according to CAN_ELIMINATE . It is not 
replacing FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM.

 Can any one point me to solution.

Thanks in advance,
Sumanth

RE: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

[venkat]

I faced similar problem. 

I have set 'flag_omit_frame_pointer = TRUE' in the function written for the
macro OVERRIDE_OPTIONS.


> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
> Behalf Of sumanth
> Sent: Wednesday, April 22, 2009 10:51 AM
> To: gnu
> Subject: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.
> 
> Hi,
>     I have a doubt regarding target macros ELIMINABLE_REGS and
> CAN_ELIMINATE.
>     I defined eliminable regs as
>     #define ELIMINABLE_REGS  { \
>         {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} , \
>         {FRAME_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM} , \
>         {HARD_FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} }
>    and CAN_ELIMINATE(FROM, TO) as if it has to replace
> FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM
>    whenever !(frame_pointer_needed).
> 
>    But, my code generated is not according to CAN_ELIMINATE . It is not
> replacing FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM.
> 
>  Can any one point me to solution.
> 
> Thanks in advance,
> Sumanth

Re: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

[sumanth]

hi venkat,
                and still the problem is same.
venkat wrote:
> I faced similar problem. 
>
> I have set 'flag_omit_frame_pointer = TRUE' in the function written for the
> macro OVERRIDE_OPTIONS.
>
>
>   
>> -----Original Message-----
>> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
>> Behalf Of sumanth
>> Sent: Wednesday, April 22, 2009 10:51 AM
>> To: gnu
>> Subject: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.
>>
>> Hi,
>>     I have a doubt regarding target macros ELIMINABLE_REGS and
>> CAN_ELIMINATE.
>>     I defined eliminable regs as
>>     #define ELIMINABLE_REGS  { \
>>         {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} , \
>>         {FRAME_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM} , \
>>         {HARD_FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} }
>>    and CAN_ELIMINATE(FROM, TO) as if it has to replace
>> FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM
>>    whenever !(frame_pointer_needed).
>>
>>    But, my code generated is not according to CAN_ELIMINATE . It is not
>> replacing FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM.
>>
>>  Can any one point me to solution.
>>
>> Thanks in advance,
>> Sumanth
>>     
>
>
>
>
>   

RE: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

[venkat]

Then please check INITIAL_ELIMINATION_OFFSET macro definitions.

(Snip from GCC internals)
This macro is similar to INITIAL_FRAME_POINTER_OFFSET. It specifies the
initial difference between the specified pair of registers. This macro must
be defined if ELIMINABLE_REGS is defined.
(Snip)

> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
> Behalf Of sumanth
> Sent: Wednesday, April 22, 2009 12:32 PM
> To: venkat
> Cc: 'gnu'
> Subject: Re: QUery regarding target macros ELIMINABLE_REGS and
> CAN_ELIMINATE.
> 
> hi venkat,
>                 and still the problem is same.
> venkat wrote:
> > I faced similar problem.
> >
> > I have set 'flag_omit_frame_pointer = TRUE' in the function written for
> the
> > macro OVERRIDE_OPTIONS.
> >
> >
> >
> >> -----Original Message-----
> >> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
> >> Behalf Of sumanth
> >> Sent: Wednesday, April 22, 2009 10:51 AM
> >> To: gnu
> >> Subject: QUery regarding target macros ELIMINABLE_REGS and
> CAN_ELIMINATE.
> >>
> >> Hi,
> >>     I have a doubt regarding target macros ELIMINABLE_REGS and
> >> CAN_ELIMINATE.
> >>     I defined eliminable regs as
> >>     #define ELIMINABLE_REGS  { \
> >>         {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} , \
> >>         {FRAME_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM} , \
> >>         {HARD_FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} }
> >>    and CAN_ELIMINATE(FROM, TO) as if it has to replace
> >> FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM
> >>    whenever !(frame_pointer_needed).
> >>
> >>    But, my code generated is not according to CAN_ELIMINATE . It is not
> >> replacing FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM.
> >>
> >>  Can any one point me to solution.
> >>
> >> Thanks in advance,
> >> Sumanth
> >>
> >
> >
> >
> >
> >

Re: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

[Ian Lance Taylor]

sumanth <sumanth.gundapneni@redpinesignals.com> writes:

>   But, my code generated is not according to CAN_ELIMINATE . It is not
> replacing FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM.

Frame pointer elimination is based on FRAME_POINTER_REQUIRED.  You need
to set both that and CAN_ELIMINATE to prevent frame pointer elimination.

Ian

Re: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

[sumanth]

Hi Ian,
Thanks for the reply.
Currently I am using  #define FRAME_POINTER_REQUIRED  
(current_function_calls_alloca)
How ever i tried with #define FRAME_POINTER_REQUIRED  0 too and my 
result is same.
Any suggestions are  welcome


Thanks in advance,
Sumanth
Ian Lance Taylor wrote:
> sumanth <sumanth.gundapneni@redpinesignals.com> writes:
>
>   
>>   But, my code generated is not according to CAN_ELIMINATE . It is not
>> replacing FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM.
>>     
>
> Frame pointer elimination is based on FRAME_POINTER_REQUIRED.  You need
> to set both that and CAN_ELIMINATE to prevent frame pointer elimination.
>
> Ian
>
>
>   

Re: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

[Ian Lance Taylor]

sumanth <sumanth.gundapneni@redpinesignals.com> writes:

> Ian Lance Taylor wrote:
>> sumanth <sumanth.gundapneni@redpinesignals.com> writes:
>>
>>   
>>>   But, my code generated is not according to CAN_ELIMINATE . It is not
>>> replacing FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM.
>>>     
>>
>> Frame pointer elimination is based on FRAME_POINTER_REQUIRED.  You need
>> to set both that and CAN_ELIMINATE to prevent frame pointer elimination.
>
> Currently I am using  #define FRAME_POINTER_REQUIRED
> (current_function_calls_alloca)
> How ever i tried with #define FRAME_POINTER_REQUIRED  0 too and my
> result is same.
> Any suggestions are  welcome

If FRAME_POINTER_REQUIRED is 0, and ELIMINABLE_REGS is defined, and
CAN_ELIMINATE (FRAME_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM) returns
0, then the register should not be eliminated.

I may have gotten confused about what you want.  Do you want
FRAME_POINTER_REGNUM replaced by HARD_FRAME_POINTER_REGNUM or not?  If
you do want it replaced, then CAN_ELIMINATE must return 1 for that case.
If you do not want it eliminated, then I think that both must be real
registers.

Ian

Re: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

[sumanth]

Hi
           I tried what you suggested and now my soft frame pointer gets 
eliminated with hard frame pointer.
  The problem here is I am not getting the correct debugging information 
generated by compiler for local variables.
  Eg: HARD_FRAME_POINTER_REGNUM is R11 FRAME_POINTER_REGNUM is RFP.
  Now , as you mentioned I replaced RFP with R11 , my debugging 
information gets corrupted.
  ""But if I hard code  my FRAME_POINTER_REGNUM  with R11 instead of 
RFP  , I get the correct debugging information""
  and I do have certain problems in build with above replacement and the 
generated code is not as reliable as expected.
 Any suggestions are welcome .

Thanks in advance,
Sumanth G 
Ian Lance Taylor wrote:
> sumanth <sumanth.gundapneni@redpinesignals.com> writes:
>
>   
>> Ian Lance Taylor wrote:
>>     
>>> sumanth <sumanth.gundapneni@redpinesignals.com> writes:
>>>
>>>   
>>>       
>>>>   But, my code generated is not according to CAN_ELIMINATE . It is not
>>>> replacing FRAME_POINTER_REGNUM  with HARD_FRAME_POINTER_REGNUM.
>>>>     
>>>>         
>>> Frame pointer elimination is based on FRAME_POINTER_REQUIRED.  You need
>>> to set both that and CAN_ELIMINATE to prevent frame pointer elimination.
>>>       
>> Currently I am using  #define FRAME_POINTER_REQUIRED
>> (current_function_calls_alloca)
>> How ever i tried with #define FRAME_POINTER_REQUIRED  0 too and my
>> result is same.
>> Any suggestions are  welcome
>>     
>
> If FRAME_POINTER_REQUIRED is 0, and ELIMINABLE_REGS is defined, and
> CAN_ELIMINATE (FRAME_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM) returns
> 0, then the register should not be eliminated.
>
> I may have gotten confused about what you want.  Do you want
> FRAME_POINTER_REGNUM replaced by HARD_FRAME_POINTER_REGNUM or not?  If
> you do want it replaced, then CAN_ELIMINATE must return 1 for that case.
> If you do not want it eliminated, then I think that both must be real
> registers.
>
> Ian
>
>
>   

Re: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

[Ian Lance Taylor]

sumanth <sumanth.gundapneni@redpinesignals.com> writes:

>           I tried what you suggested and now my soft frame pointer
> gets eliminated with hard frame pointer.
>  The problem here is I am not getting the correct debugging
> information generated by compiler for local variables.
>  Eg: HARD_FRAME_POINTER_REGNUM is R11 FRAME_POINTER_REGNUM is RFP.
>  Now , as you mentioned I replaced RFP with R11 , my debugging
> information gets corrupted.
>  ""But if I hard code  my FRAME_POINTER_REGNUM  with R11 instead of
> RFP  , I get the correct debugging information""
>  and I do have certain problems in build with above replacement and
> the generated code is not as reliable as expected.

In what way is the debugging information incorrect?  Is it incorrect for
local variables, or function parameters, or both?

Ian

Re: QUery regarding target macros ELIMINABLE_REGS and CAN_ELIMINATE.

[sumanth]

Debugging information generated for local variable's address is wrong .
All my local variables and function arguments should be in between frame 
pointer and stack pointer .
My assembly code generated places the values of variables in specified 
locations .
 But the variables address generated by compiler is not pointing to the 
location as per assembly code.

Thanks in advance
Sumanth

Ian Lance Taylor wrote:
> sumanth <sumanth.gundapneni@redpinesignals.com> writes:
>
>   
>>           I tried what you suggested and now my soft frame pointer
>> gets eliminated with hard frame pointer.
>>  The problem here is I am not getting the correct debugging
>> information generated by compiler for local variables.
>>  Eg: HARD_FRAME_POINTER_REGNUM is R11 FRAME_POINTER_REGNUM is RFP.
>>  Now , as you mentioned I replaced RFP with R11 , my debugging
>> information gets corrupted.
>>  ""But if I hard code  my FRAME_POINTER_REGNUM  with R11 instead of
>> RFP  , I get the correct debugging information""
>>  and I do have certain problems in build with above replacement and
>> the generated code is not as reliable as expected.
>>     
>
> In what way is the debugging information incorrect?  Is it incorrect for
> local variables, or function parameters, or both?
>
> Ian
>
>
>   

internal compiler error: in avail_expr_eq, at tree-ssa-dom.c:2055

[John Fine]

The thing I'm compiling is too complex (and proprietary) to even attempt 
to create an example I could provide in a bug report.

I'm using gcc4.3.2

The error message is

internal compiler error: in avail_expr_eq, at tree-ssa-dom.c:2055

The reported line in my file being compiled (with all the names changed) is
template<> inline void A<B>::C(D& E, F G)

Where
A is a class template
B and D are simple classes
F is a typedef defined in a base class of A (as a pointer to a simple class)

That line is correctly followed by the function body.

That same construct (changing only B) appears in hundreds of other places with no problems.

Can you give me any suggestions on what to try and/or generally what the error message might mean?

Re: internal compiler error: in avail_expr_eq, at tree-ssa-dom.c:2055

[Ian Lance Taylor]

John Fine <johnsfine@verizon.net> writes:

> The thing I'm compiling is too complex (and proprietary) to even
> attempt to create an example I could provide in a bug report.
>
> I'm using gcc4.3.2
>
> The error message is
>
> internal compiler error: in avail_expr_eq, at tree-ssa-dom.c:2055
>
> The reported line in my file being compiled (with all the names changed) is
> template<> inline void A<B>::C(D& E, F G)
>
> Where
> A is a class template
> B and D are simple classes
> F is a typedef defined in a base class of A (as a pointer to a simple class)
>
> That line is correctly followed by the function body.
>
> That same construct (changing only B) appears in hundreds of other places with no problems.
>
> Can you give me any suggestions on what to try and/or generally what the error message might mean?

An internal compiler error means a bug in the compiler.  It's
essentially impossible to say anything useful without a test case.  We
try to eliminate all known internal compiler errors before a release,
replacing them by an error message if nothing else.  So this is most
likely something new that we haven't seen before.  The line number is
meaningless except to indicate the function--the error could be
triggered by any of the code in that function or in functions that it
calls which have been inlined.

The specific problem seems to be that two statements compared as equal
but had a different hash code.  I have no idea what caused that--it
could even be due to memory corruption elsewhere in the compiler.

This probably won't help much, but I expect that you can avoid this by
compiling without optimization.

Ian

Re: internal compiler error: in avail_expr_eq, at tree-ssa-dom.c:2055

[John Fine]

Thanks for the information.  I think I understand what you said about 
the line number.  Less so, what you said about statements comparing as 
equal.  I don't understand how that might fit into the process of 
optimizing.

The problem isn't even consistent with perfectly identical (massive) 
source code.  Checking build logs, I found the same error happened twice 
out of several times the identical source code was compiled.  Rerunning 
outside of the build system (but same source code and g++ command) it 
didn't happen again.

Do any of the optimizations make decisions based on the available 
physical ram of the system on which the compile is running?

The system has 8GB of physical ram plus plenty of swap space.  On the 
two occasions when it failed, it was one of 8 large compiles running.  
Under such conditions almost all the 8GB is used by the compile 
processes, memory for caching is pushed down to just a few hundred MB 
and a moderate amount of swap space is used.  (That is a non optimal 
condition.   Running fewer compiles at once would be a little faster to 
get them all done.  But our build process can't factor size in when 
deciding how many compilers to run in parallel.  Most compiles take less 
memory so 8 way parallel is optimal on that system).

I'm just mentioning the performance issues, not directly asking about 
them.  What I'm really asking about is whether the memory pressure 
affects the optimization decisions rather than just the performance.  
There are some monster large functions in which optimization could take 
unreasonable amounts of time and/or memory (the function ending right 
before the reported line is one of those).  If external (from other 
processes) memory pressure affects optimizer choices, that could explain 
why this failure happened only twice out of several compiles of the same 
source code.  If the compiler is supposed to be more deterministic, it 
may be much harder to explain.

I'm used to non deterministic behavior from the Intel10 compiler in 
Windows run 8 copies in parallel (on better processors with 16GB of 
ram).  It's easier to run a cleanup (retry) pass for the failures at the 
end of the build script than to solve them or to run fewer in parallel.  
I guess now I need the same for gcc and Linux.   When I wrote the first 
email about this I didn't yet realize the builds of that source that had 
worked were from perfectly identical source code to the two that 
failed.  That's bad news for any hope f solving it (though I'm open to 
suggestions) but good news for my build process.  I don't really need to 
solve it, just run a clean up pass for the failure(s).   (So far just 
one of MANY files in the build process failed and it probably fails at 
low probability).


Ian Lance Taylor wrote:
> The line number is
> meaningless except to indicate the function--the error could be
> triggered by any of the code in that function or in functions that it
> calls which have been inlined.
>
> The specific problem seems to be that two statements compared as equal
> but had a different hash code.  I have no idea what caused that--it
> could even be due to memory corruption elsewhere in the compiler.
>
> This probably won't help much, but I expect that you can avoid this by
> compiling without optimization.
>
>
>   

Re: internal compiler error: in avail_expr_eq, at tree-ssa-dom.c:2055

[Ian Lance Taylor]

John Fine <johnsfine@verizon.net> writes:

> Thanks for the information.  I think I understand what you said about
> the line number.  Less so, what you said about statements comparing as
> equal.  I don't understand how that might fit into the process of
> optimizing.

The internal data structures built by the optimizer compared as equal
even though their hash code were different.  This has nothing much to do
with your program, and has everything to do with the data structures
built within gcc.


> The problem isn't even consistent with perfectly identical (massive)
> source code.  Checking build logs, I found the same error happened
> twice out of several times the identical source code was compiled.
> Rerunning outside of the build system (but same source code and g++
> command) it didn't happen again.

That is extremely weird.


> Do any of the optimizations make decisions based on the available
> physical ram of the system on which the compile is running?

No.  However, gcc's internal garbage collector does make such decisions.
This is not supposed to affect the compiler's output, but of course if
there is a bug it might.

Ian

Re: internal compiler error: in avail_expr_eq, at tree-ssa-dom.c:2055

[John Fine]

I want to be sure I really understood you on that point.

The internal garbage collector is influenced by physical ram use by 
other processes?

This in not an issue of virtual memory limits in the current process (it 
is AMD64 and VIRT is under2GB).

This is not an issue of system wide commit level (the swap space is 
slightly larger than the VIRT total across all processes, and not all of 
that VIRT even needs one of physical ram or swap, and there is 8GB of 
physical ram).

But physical ram is somewhat low (the compiles each have slightly lower 
RES memory than the same compile would have if it were running alone and 
cache is much lower, so .hpp files are being reread rather than always 
found in cache).

Do you happen to know what method the internal garbage collector uses to 
ask about physical ram in order to be affected by it?

I understand how hard it would be to look for a bug that depends on 
garbage collector choices in a very big compile.  So I guess I should be 
very glad the compiler crashes rather than silently producing wrong 
results.  But I would like a better understanding myself of what 
influences compiler behavior.

Ian Lance Taylor wrote:
> No.  However, gcc's internal garbage collector does make such decisions.
> This is not supposed to affect the compiler's output, but of course if
> there is a bug it might.
>
>   

Re: internal compiler error: in avail_expr_eq, at tree-ssa-dom.c:2055

[Ian Lance Taylor]

John Fine <johnsfine@verizon.net> writes:

> The internal garbage collector is influenced by physical ram use by
> other processes?

I guess I don't know for sure.  It's definitely affected by the values
returned by sysconf (_SC_PHYS_PAGES) and getrlimit ({RLIMIT_AS,
RLIMIT_DATA, RLIMIT_RSS}).  I don't know whether those values are all
independent of what other processes are doing at the time they are
called.

Ian