Re: old aliasing bug: fixed?

[Albert Cahalan]

On Thu, Sep 30, 2010 at 5:39 AM, Richard Guenther
 wrote:
> On Thu, Sep 30, 2010 at 9:54 AM, Albert Cahalan  wrote:
>> int weird(float *fp){
>>        // access an int as an int (see caller),
>>        // so not an aliasing violation
>>        return *(int*)fp;
>> }
>> int main(int argc, char *argv[]){
>>        return weird((float*)&argc);
>> }
>>
>> I just tried this code with gcc 4.4.5 on 32-bit powerpc using -O2 -W -Wall.
>> Assembly code for the weird function looks OK, both inlined and not, but
>> that certainly isn't proof that gcc will always tolerate such code.
>> I recall that there were problems handling this type of code. (never mind
>> any non-conformant callers that actually pass a pointer to a float -- not
>> that gcc would be able to see them in separately compiled files)
>>
>> So, is it fixed now? (what gcc version?) If not, is it at least fixed
>> if I change "float" to "void" and/or "unsigned char"?
>>
>> BTW, oddly it looks like gcc tolerates a genuine aliasing violation
>> as well now. (passing the value as a float) Of course, that may just
>> be my luck with the optimizer.
>
> I indeed fixed the above problem at some point (4.1 may be still
> broken, 4.3 should be fixed I think).
>
> We're trying to tolerate genuine alias violations if we can see
> what the user intended (in compiler-speak, when we detect
> a must-alias relationship we do not try to disabiguate using
> type-based alias analysis).  That's just being nice to users and
> not breaking their code just because we can.

I've been trying to come up with an example where either:

a. gcc gains optimization from type-based alias analysis
b. traditional assumptions result in breakage

I am no longer able to find either. Is it safe to consider the
type-based aliasing to be essentially disabled now?

Re: Hooks, macros and target configuration

[Richard Guenther]

On Tue, Oct 19, 2010 at 11:55 PM, Joseph S. Myers
 wrote:
> My ongoing work to implement the multilib selection changes described
> at  will in due
> course require option-related hooks to be shared between the driver
> and the compilers proper (cc1 etc.).  As we do not currently have a
> hooks system in the driver, it seems appropriate to consider what
> design we want for hooks extended into this part of the compiler -
> and, more generally, what we would like the system for target
> configuration to look like.
>
> (In this message I only consider designs for C.  It is certainly
> possible that in future a native C++ approach with less heavy use of
> macros may be used, but I think the same general issues arise.)
>
> The basic design for target hooks was implemented by Neil Booth in
> June 2001 following a discussion
>  I started
> (this was not the first time the principle of moving away from macros
> had come up), with langhooks following later that year, the
> targhooks.c system for incremental transition of individual macros to
> hooks being added in 2003, and automatic generation of much of the
> boilerplate code from a single .def file being added much more
> recently by Joern Rennecke; we now have about 300 target hooks.  The
> point that such functions should be linkable into the driver came up
> in the second message of that thread.
>
> The motivations for moving from macros to hooks remain as discussed
> then: cleaner design, better-specified interfaces with prototypes (so
> eliminating one cause of warnings building target-independent files
> only when configured for some targets, or errors from code conditioned
> with #if) and potentially the ability to swap out target structures
> for multi-target compiler binaries.
>
> In general, the existing target hooks are defined through #define
> within the target .c file, before the targetm variable is defined with
> its initializer.  This works well for hooks that largely depend on the
> target architecture alone, not on the target OS.  There are some
> exceptions where OS-dependent hooks are defined in the .h files listed
> in $tm_file, and some cases where targets modify hooks at runtime
> (this should generally be for hooks that are integer or string
> constants rather than functions, though I have not checked whether any
> function hooks are also being modified at runtime).  Such cases would
> make a multi-target compiler (with each source file compiled only
> once, but multiple target OSes for a single architecture) a bit
> harder; targetm would need to move to its own .c file, with only that
> .c file being compiled separately for each target.
>
> Some target macros - which should become hooks in some form - are much
> more dependent on the target OS.  This applies, in particular, to all
> the various specs used by the driver.  Given this, my inclination is
> that the driver's targetm structure should be defined in its own .c
> file, with the macros providing its initializer generally coming from
> .h files.  This isn't very far distant from the present system for
> specs (where the macros initialize variables and otherwise the
> variables are generally what's used, potentially being modified at
> runtime when a specs file is read).
>
> The advantage as I see it would come if the target .h files could be
> split up, with the driver-only defines coming from a separate set of
> headers from those used in the core compiler.  The ones used in the
> core compiler would likely be simpler and have fewer OS dependencies.
> It might make it easier to move towards using these headers
> consistently in the order given in config.gcc as the preferred order -
> with the aim being to avoid architecture-specific cases in config.gcc
> mentioning architecture-independent headers at all.  (A case statement
> over target architectures should deal with architecture-specific
> configuration; one over OSes should deal with OS-specific
> configuration; one over pairs should deal with the combination; and
> target-independent code should put together the lists from each of
> those case statements in the standard order.)
>
> This separation of configuration for different purposes is closely
> related to the issues with hooks for option handling.  Target .h files
> configuration used in various ways, with some macros used in more than
> one way:
>
> * Definitions for use in the target's own .c files.
>
> * Definitions for use in code in the target's .md files.
>
> * Definitions for use in code in the core compiler (middle-end and
>  front ends).  tm_p.h has prototypes for use in such code, and an
>  intermediate goal in converting macros to hooks might be to convert
>  every macro that uses a function on any target, so that tm_p.h is
>  only included in the target's .c files and in the generated files
>  containing code from the .md files.
>
> * Definitions for use in

Re: old aliasing bug: fixed?

[Richard Guenther]

On Wed, Oct 20, 2010 at 10:29 AM, Albert Cahalan  wrote:
> On Thu, Sep 30, 2010 at 5:39 AM, Richard Guenther
>  wrote:
>> On Thu, Sep 30, 2010 at 9:54 AM, Albert Cahalan  wrote:
>>> int weird(float *fp){
>>>        // access an int as an int (see caller),
>>>        // so not an aliasing violation
>>>        return *(int*)fp;
>>> }
>>> int main(int argc, char *argv[]){
>>>        return weird((float*)&argc);
>>> }
>>>
>>> I just tried this code with gcc 4.4.5 on 32-bit powerpc using -O2 -W -Wall.
>>> Assembly code for the weird function looks OK, both inlined and not, but
>>> that certainly isn't proof that gcc will always tolerate such code.
>>> I recall that there were problems handling this type of code. (never mind
>>> any non-conformant callers that actually pass a pointer to a float -- not
>>> that gcc would be able to see them in separately compiled files)
>>>
>>> So, is it fixed now? (what gcc version?) If not, is it at least fixed
>>> if I change "float" to "void" and/or "unsigned char"?
>>>
>>> BTW, oddly it looks like gcc tolerates a genuine aliasing violation
>>> as well now. (passing the value as a float) Of course, that may just
>>> be my luck with the optimizer.
>>
>> I indeed fixed the above problem at some point (4.1 may be still
>> broken, 4.3 should be fixed I think).
>>
>> We're trying to tolerate genuine alias violations if we can see
>> what the user intended (in compiler-speak, when we detect
>> a must-alias relationship we do not try to disabiguate using
>> type-based alias analysis).  That's just being nice to users and
>> not breaking their code just because we can.
>
> I've been trying to come up with an example where either:
>
> a. gcc gains optimization from type-based alias analysis
> b. traditional assumptions result in breakage
>
> I am no longer able to find either. Is it safe to consider the
> type-based aliasing to be essentially disabled now?

int foo (int *i, float *f)
{
  *i = 1;
  *f = 0;
  return *i;
}

is a case for a.  We optimize this to return 1.  I don't quite understand
what you seek for with b, but for example for

int foo (void)
{
  int i = 1;
  *(float *)&i = 0.0;
  return i;
}

GCC is allowed to optimize it to return 1, but for example GCC 4.6
will optimize it to return 0 as the user probably expected because
when optimizing the load of i we now see a must-alias store to it.

Richard.

Re: GCC RTX generation question

[Radu Hobincu]

> "Radu Hobincu"  writes:
>
>> 1. I have the following code:
>>
>> ---
>> extern void doSmth();
>>
>> void bugTest(){
>>  doSmth();
>> }
>> ---
>>
>> It compiles fine with -O0, but when I try to use -O3, I get the
>> following
>> compiler error:
>>
>> -
>> test0.c:13: error: unrecognizable insn:
>> (call_insn 7 6 8 3 test0.c:12 (call (mem:SI (mem:SI (reg/f:SI 41) [0 S4
>> A32]) [0 S4 A32])
>> (const_int 0 [0x0])) -1 (nil)
>> (nil))
>> test0.c:13: internal compiler error: in extract_insn, at recog.c:2048
>> -
>>
>> I don't understand why the compiler generates (call (mem (mem (reg)
>> )))...
>> and also, I was under the impression that any address should checked by
>> the GO_IF_LEGITIMATE_ADDRESS macro, but I checked and the macro doesn't
>> receive a (mem (reg)) rtx to verify. This is most likely a failure of my
>> part to describe something correctly, but the error message isn't very
>> explicit.
>
> This looks like gcc is loading the function address from memory.  Is
> that required for your target?  Assuming it is, then the problem seems
> to be that the operand predicate for your call instruction accepts
> (mem:SI (mem:SI (reg:SI 41))).  That seems odd.

Thank you, you are right, the description of "call" was way off. Fixed it
and it works now with any optimization level.


>> 2. I have another piece of code that fails to compile with -O3.
>>
>> -
>> struct desc{
>>  int int1;
>>  int int2;
>>  int int3;
>> };
>>
>> int bugTest(struct desc *tDesc){
>>  return *((int*)(tDesc->int1 + 16));
>> }
>> --
>
> That code looks awfully strange.  Is that an integer or a pointer?
>
>> This time the compiler crashes with a segmentation fault. From what I
>> could dig up with gdb, the compilers tries to make a LIBCALL for a
>> memcopy, but I'm not really sure why. At the end is the back-trace of
>> the
>> crash.
>
> gcc is invoking memmove.  This is happening in the return statement.
> For some reason gcc thinks that the function returns a struct.  Your
> example does not return a struct..  I can not explain this.

Ok, after changing both PARM_BOUNDARY and STACK_BOUNDARY from 8 to 32, now
the compiler no longer crashes with segmentation fault, but it still
generates a memmove syscall.

To explain the code, I have a structure holding some info about a serial
interface. One of the fields of the structure is the base address at which
the serial is mapped in the main memory. Offseted by 16 bytes is the
address from which I can read the available byte count received by the
serial. It would probably be a better practice to define the base as
(*int) rather than (int) but this should work as well. I tried both

return *((int*)tDesc->int1 + 4);
return *((int*)(tDesc->int1 + 16));

The result is the same: a system call. Is this in any way related to the
back-end definition which I might have done wrong, or is it middle-end
related?

Regards,
Radu

Re: GCC RTX generation question

[Ian Lance Taylor]

"Radu Hobincu"  writes:

>>> 2. I have another piece of code that fails to compile with -O3.
>>>
>>> -
>>> struct desc{
>>> int int1;
>>> int int2;
>>> int int3;
>>> };
>>>
>>> int bugTest(struct desc *tDesc){
>>> return *((int*)(tDesc->int1 + 16));
>>> }
>>> --
>>
>> That code looks awfully strange.  Is that an integer or a pointer?
>>
>>> This time the compiler crashes with a segmentation fault. From what I
>>> could dig up with gdb, the compilers tries to make a LIBCALL for a
>>> memcopy, but I'm not really sure why. At the end is the back-trace of
>>> the
>>> crash.
>>
>> gcc is invoking memmove.  This is happening in the return statement.
>> For some reason gcc thinks that the function returns a struct.  Your
>> example does not return a struct..  I can not explain this.
>
> Ok, after changing both PARM_BOUNDARY and STACK_BOUNDARY from 8 to 32, now
> the compiler no longer crashes with segmentation fault, but it still
> generates a memmove syscall.
>
> To explain the code, I have a structure holding some info about a serial
> interface. One of the fields of the structure is the base address at which
> the serial is mapped in the main memory. Offseted by 16 bytes is the
> address from which I can read the available byte count received by the
> serial. It would probably be a better practice to define the base as
> (*int) rather than (int) but this should work as well. I tried both
>
> return *((int*)tDesc->int1 + 4);
> return *((int*)(tDesc->int1 + 16));
>
> The result is the same: a system call. Is this in any way related to the
> back-end definition which I might have done wrong, or is it middle-end
> related?

I don't know.  There is something very odd about the fact that gcc
thinks that you are returning a struct when you are actually returning
an int.  In particular, as far as I can see, cfun->returns_struct is
true.  I think you need to try to figure out why that is happening.

Ian

Re: Questions about selective scheduler and PowerPC

[Pat Haugen]

 On 10/18/2010 10:33 AM, Jeff Law wrote:

 On 10/18/10 09:22, David Edelsohn wrote:
On Mon, Oct 18, 2010 at 8:27 AM, Nathan 
Froyd  wrote:

On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote:

3. The aforementioned rs6000 hack rs6000_issue_rate was added by

2003-03-03  David Edelsohn

 * config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): 
Delete.

 (TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete.
 (rs6000_variable_issue): Do not return negative value.
 (rs6000_issue_rate): Uniformly set issue rate to 1 for first
 scheduling pass.

, which was more than 7 years ago. Is this still needed now?

I asked David about this on IRC several days ago.  He indicated that it
was necessary to prevent the first scheduling pass from unnecessarily
increasing register pressure.  I don't know whether anybody has 
actually

tested it with recent GCC, though presumably it did help when it was
installed.

I am not sure when it last was re-checked, but it was checked after
sched_pressure was added.  When that option is not enabled, the
issue_rate change still helped.
Did anyone check this after Bernd's work to better handle allocation 
of double-word pseudos in IRA?  That code should be handling the false 
conflicts created by movement of clobbers.


Running CPU2006, with the hack removed I see about a 1% improvement in 
specint (10% in 456.hmmer, a couple others in the 3% range, -3% 
401.bzip2) and a 1% degradation in specfp (mainly due to a 13% 
degradation in 435.gromacs). But 454.calculix also fails for me (output 
miscompare), so assume we're generating incorrect code for some reason 
with the hack removed.


-Pat

Re: Questions about selective scheduler and PowerPC

[Jie Zhang]

On 10/21/2010 04:08 AM, Pat Haugen wrote:

On 10/18/2010 10:33 AM, Jeff Law wrote:

On 10/18/10 09:22, David Edelsohn wrote:

On Mon, Oct 18, 2010 at 8:27 AM, Nathan
Froyd wrote:

On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote:

3. The aforementioned rs6000 hack rs6000_issue_rate was added by

2003-03-03 David Edelsohn

* config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete.
(TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete.
(rs6000_variable_issue): Do not return negative value.
(rs6000_issue_rate): Uniformly set issue rate to 1 for first
scheduling pass.

, which was more than 7 years ago. Is this still needed now?

I asked David about this on IRC several days ago. He indicated that it
was necessary to prevent the first scheduling pass from unnecessarily
increasing register pressure. I don't know whether anybody has actually
tested it with recent GCC, though presumably it did help when it was
installed.

I am not sure when it last was re-checked, but it was checked after
sched_pressure was added. When that option is not enabled, the
issue_rate change still helped.

Did anyone check this after Bernd's work to better handle allocation
of double-word pseudos in IRA? That code should be handling the false
conflicts created by movement of clobbers.


Running CPU2006, with the hack removed I see about a 1% improvement in
specint (10% in 456.hmmer, a couple others in the 3% range, -3%
401.bzip2) and a 1% degradation in specfp (mainly due to a 13%
degradation in 435.gromacs). But 454.calculix also fails for me (output
miscompare), so assume we're generating incorrect code for some reason
with the hack removed.

Thanks for benchmarking! Since there is a bug in max_issue, issue_rate 
is not really honored. Could you try this patch


http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01719.html

with and without the hack?


Regards,
--
Jie Zhang
CodeSourcery