Re: debug strings output order is arbitrary

[Richard Biener]

On Sun, Mar 16, 2014 at 3:58 AM, Martin Uecker  wrote:
>
> Hi list,
>
> the strings in the ".debug_str" section are output
> in an arbitrary order. Could this be changed?
>
> The function 'output_indirect_strings' in 'gcc/dwarf2out.c'
> uses htab_traverse which then outputs the string in the
> order they appear in the hash table. Instead, it would
> be nicer to output them based on their labels (which are
> assigned based on the order of creation).
>
> This would minimize differences between builds with
> slightly different build environments, e.g. directory.

Can you propose a patch?  Note that at creation time only
the string itself is known, so sorting after the string may
be another possibility.

Richard.

Re: [gsoc 2014] moving fold-const patterns to gimple

[Richard Biener]

On Sun, Mar 16, 2014 at 1:21 PM, Prathamesh Kulkarni
 wrote:
> In c_expr::c_expr, shouldn't OP_C_EXPR be passed to operand
> constructor instead of OP_EXPR ?

Indeed - I have committed the fix.

Thanks,
Richard.

> This caused segfault for patterns when "simplification" operand was
> only c_expr (patch attached).
>
> * genmatch.c (c_expr::c_expr): use OP_C_EXPR instead of OP_EXPR in
> call to operand constructor.

Re: builtin function - novops

[Richard Biener]

On Mon, Mar 17, 2014 at 1:59 AM, Hariharan Sandanagobalane
 wrote:
> Hello,
> This question is similar to one raised by bingfeng here
>
> http://gcc.gnu.org/ml/gcc/2010-04/msg00241.html
>
> In our private port based on GCC 4.8.1, i want to define a builtin function
> for multiply and accumulate. The function uses the input parameters and
> modifies the accumulator. The accumulator can be read using special builtin
> functions. If i had
>
> __builtin_mac (s->x[0], s->x[1]);
> __builtin_mac (s->x[0] + 5, s->x[1] + 5);
>
> I want s->x[0,1] to be loaded once and used for both invocations.
>
> I can not use either pure or constant since that will eliminate these
> functions. I tried using novops within builtin declaration in the port, but
> that doesn't seem to do the trick either. What attribute should i be using
> in this scenario?

There isn't (and there can't be) a magic attribute that will make the compiler
know that implicit dependency between those builtins.

The only "implicit" dependency we have is "global memory" which
means "no attribute" is the correct attribute to use.

The other variant is to make the dependency explicit - which is hard
as mac already has an output and a call can at most have one.

There are several possible work-arounds

- add a 2nd output via a address argument &SPECIAL_DECL and add a "fn
spec" attribute to the builtin that tells the alias machinery about
the fns behavior (doesn't work - "fn spec" can't make the function
otherwise const, something we'd need to fix)

- do the above but special-case the builtins in the alias
disambiguators to only consider memory dependences on that 2nd "fake"
output

- model the builtins not as builtins but as inline asm which can have
multiple outputs

Richard.

> Thanks and regards
> Hari

RE: builtin function - novops

[Bingfeng Mei]

In our case, we make MAC register explicit by defining a new
type of register (data type). To use your mac instruction, you must have
a first instruction to only write to the mac register. In the
following mac builtins, the mac register can be both input/output
and therefore dependency is respected and your builtins won't
be optimized away. This is useful especially if you have multiple
mac registers and requires gcc to do register allocation.

Bingfeng

-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com] 
Sent: 17 March 2014 09:12
To: Hariharan Sandanagobalane
Cc: Bingfeng Mei; Andrew Haley; GCC Development
Subject: Re: builtin function - novops

On Mon, Mar 17, 2014 at 1:59 AM, Hariharan Sandanagobalane
 wrote:
> Hello,
> This question is similar to one raised by bingfeng here
>
> http://gcc.gnu.org/ml/gcc/2010-04/msg00241.html
>
> In our private port based on GCC 4.8.1, i want to define a builtin function
> for multiply and accumulate. The function uses the input parameters and
> modifies the accumulator. The accumulator can be read using special builtin
> functions. If i had
>
> __builtin_mac (s->x[0], s->x[1]);
> __builtin_mac (s->x[0] + 5, s->x[1] + 5);
>
> I want s->x[0,1] to be loaded once and used for both invocations.
>
> I can not use either pure or constant since that will eliminate these
> functions. I tried using novops within builtin declaration in the port, but
> that doesn't seem to do the trick either. What attribute should i be using
> in this scenario?

There isn't (and there can't be) a magic attribute that will make the compiler
know that implicit dependency between those builtins.

The only "implicit" dependency we have is "global memory" which
means "no attribute" is the correct attribute to use.

The other variant is to make the dependency explicit - which is hard
as mac already has an output and a call can at most have one.

There are several possible work-arounds

- add a 2nd output via a address argument &SPECIAL_DECL and add a "fn
spec" attribute to the builtin that tells the alias machinery about
the fns behavior (doesn't work - "fn spec" can't make the function
otherwise const, something we'd need to fix)

- do the above but special-case the builtins in the alias
disambiguators to only consider memory dependences on that 2nd "fake"
output

- model the builtins not as builtins but as inline asm which can have
multiple outputs

Richard.

> Thanks and regards
> Hari

jump_table_data and active_insn_p

[Paulo Matos]

Why is jump_table_data an active_insn?
int
active_insn_p (const_rtx insn)
{
  return (CALL_P (insn) || JUMP_P (insn)
  || JUMP_TABLE_DATA_P (insn) /* FIXME */
  || (NONJUMP_INSN_P (insn)
  && (! reload_completed
  || (GET_CODE (PATTERN (insn)) != USE
  && GET_CODE (PATTERN (insn)) != CLOBBER;
}

It is clear that someone [Steven Bosscher] thought it needs fixing but what's 
the problem with just removing it from the OR-expression?

Cheers,

Paulo Matos

Re: Integration of ISL code generator into Graphite

[Mircea Namolaru]

Hi,

First, I fully agree that integration of the ISL code generator into Graphite 
will be an
important step forward for Graphite development.
 
Regarding the implementation I have a question - why a new AST-like 
representation is needed ?
It is not possible to generate the code directly from the ISL AST (with 
possible addition of 
new attributes/transformations) ?

Regards, Mircea

- Original Message -
> From: "Roman Gareev" 
> To: gcc@gcc.gnu.org
> Cc: "Tobias Grosser" , "Albert Cohen" 
> , "Mircea Namolaru"
> 
> Sent: Friday, March 14, 2014 9:18:40 PM
> Subject: Integration of ISL code generator into Graphite
> 
> Dear gcc contributors,
> 
> I am going to try to participate in Google Summer of Code 2014. My project
> is "Integration of ISL code generator into Graphite".
> 
> My proposal can be found at on the following link
> https://drive.google.com/file/d/0B2Wloo-931AoTWlkMzRobmZKT1U/edit?usp=sharing.
> I would be very grateful for your comments, feedback and ideas about
> its
> improvement.
> 
> P.S. Sorry for the copy of this message, the previous one was declined by
> the MAILER-DAEMON.
> 
> -
> 
> Roman Gareev
> 

RedHat patch not found in mainline gcc

[Stefan Ring]

At the company where I work, we have a large program using Boost
Python (1.54). We do our product builds for RHEL 5 and recently
started building using gcc 4.8 from RedHat devtoolset 2 for
performance. This works well, except for one system where it would
deterministically crash. I traced it to an old version of libgcc, and
specifically this patch, which RedHat applied to its 5.5 release in
2009: 
.
I built libgcc myself with and without the patch, with the program
crashing reliably without the patch, and no crash with the patch
applied. Unfortunately, gdb does not show a meaningful stack trace, at
least not the old version from RHEL 5.

When trying to find out a bit more about the patch, I was rather
surprised to see that (1) it is not applied to the mainline gcc code
and (2) it still applies cleanly. Since I don't have a good stack
trace, I cannot even try to build a suitable reproducer at the moment.

Is there a good reason for not having it in mainline gcc? I suppose it
got lost or forgotten somehow, and that it would be good to have it
applied.

Re: Integration of ISL code generator into Graphite

[Roman Gareev]

Hi Mircea,

thank you for your comment! I wanted to say, that this AST-like
representation is an ISL AST containing only loops, conditions, and
statements (basic blocks). It will be differ from a CLooG AST in
representation of AST and, possibly, additional options of ISL AST
generation.

I'll try to eliminate this ambiguity in an improved version of the proposal.

2014-03-17 21:47 GMT+06:00 Mircea Namolaru :
> Hi,
>
> First, I fully agree that integration of the ISL code generator into Graphite 
> will be an
> important step forward for Graphite development.
>
> Regarding the implementation I have a question - why a new AST-like 
> representation is needed ?
> It is not possible to generate the code directly from the ISL AST (with 
> possible addition of
> new attributes/transformations) ?
>
> Regards, Mircea
>
> - Original Message -
>> From: "Roman Gareev" 
>> To: gcc@gcc.gnu.org
>> Cc: "Tobias Grosser" , "Albert Cohen" 
>> , "Mircea Namolaru"
>> 
>> Sent: Friday, March 14, 2014 9:18:40 PM
>> Subject: Integration of ISL code generator into Graphite
>>
>> Dear gcc contributors,
>>
>> I am going to try to participate in Google Summer of Code 2014. My project
>> is "Integration of ISL code generator into Graphite".
>>
>> My proposal can be found at on the following link
>> https://drive.google.com/file/d/0B2Wloo-931AoTWlkMzRobmZKT1U/edit?usp=sharing.
>> I would be very grateful for your comments, feedback and ideas about
>> its
>> improvement.
>>
>> P.S. Sorry for the copy of this message, the previous one was declined by
>> the MAILER-DAEMON.
>>
>> -
>>
>> Roman Gareev
>>



-- 

   Cheers, Roman Gareev.

Re: debug strings output order is arbitrary

[Martin Uecker]

Am Mon, 17 Mar 2014 09:44:53 +0100
schrieb Richard Biener :

> On Sun, Mar 16, 2014 at 3:58 AM, Martin Uecker  
> wrote:
> >
> > Hi list,
> >
> > the strings in the ".debug_str" section are output
> > in an arbitrary order. Could this be changed?
> >
> > The function 'output_indirect_strings' in 'gcc/dwarf2out.c'
> > uses htab_traverse which then outputs the string in the
> > order they appear in the hash table. Instead, it would
> > be nicer to output them based on their labels (which are
> > assigned based on the order of creation).
> >
> > This would minimize differences between builds with
> > slightly different build environments, e.g. directory.
> 
> Can you propose a patch?  Note that at creation time only
> the string itself is known, so sorting after the string may
> be another possibility.

I will propose a patch.

Sorting at the end would be easiest, but one could also keep
track of the order. Is this performance critical?

Also it seems there is other stuff which is output/indexed
in hash table order, maybe this should be changed to.

Martin

Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking

[Richard Sandiford]

Matthew Fortune  writes:
>> > With these defaults, the closest supported ABI is used for each
>> > architecture based on the --with-o32-fp build option. The only one I
>> > really care about is the middle one as it makes full use of the O32
>> > FPXX ABI without a user needing to account for arch restrictions.
>> 
>> Note that --with-* options just insert a canned -mfoo=bar option under
>> certain conditions, with those conditions being the same regardless of
>> "bar".
>> So --with-o32-fp=32 should insert -mfp32 (and nothing else), --with-o32-
>> fp=64 should insert -mfp64, etc.
>> 
>> The rules should therefore be the same for both -mfp and --with-o32-fp.
>> Should:
>> 
>>   mips-*-gcc -march=mips1 -mfpxx
>> 
>> generate -mfp32 code too?  It seems counter-intuitive to me.
>> 
>> I suppose it depends on what you want -mfpxx to mean.  Do you want it to
>> mean "use the new ABI that is link-compatible with both -mfp32 and -
>> mfp64"
>> or do you want it to mean "I don't care what the FR setting is; pick
>> whatever seems best but be as flexible as possible"?  I'd assumed the
>> former, in which case using it with an architecture that doesn't support
>> it should be an error.
>
> In the end I do just want fpxx to mean use the new ABI that is
> link-compatible. I think I have managed to confuse this discussion by
> not understanding/separating vendor specific specs from generic option
> handling as you explain later in your email. I only really wish to allow
> a vendor specific config to infer a suitable default fp option from
> -march (like -mabi=32 for 32-bit arch and -mabi=n32 for 64-bit arch).

Well, for avoidance of doubt, --with has priority over the vendor-specific
choices, so really this comes down to what happens when no -mfp and
--with-o32-fp options are used.

>> If you want to go for tha latter meaning then I think we should be
>> careful to distinguish it from cases where we really are talking about
>> the new ABI variant.  E.g. an ELF file has to commit to one of the three
>> modes: you shouldn't have to look at the ELF's architecture setting in
>> order to interpret the FP setting correctly.  And IMO the assembly code
>> needs to commit to a specific mode too.  What do you think should happen
>> for:
>> 
>>   .module fp=xx
>>   .module arch=mips_n
>> 
>> Should the output be FR=X or FR=1?
>
> Well, even defining fpxx as simply being another abi variant there are
> some issues. The current .set arch= options set fp32 for 32-bit
> architectures and fp64 for 64-bit architectures which means we do have
> to come up with some definition of how fpxx interacts with this. My
> current implementation is that, for .set arch, the fp option is only
> changed if the existing setting is incompatible with the new arch. So
> carrying that logic to .module means that in the case above then the
> output would be FPXX. Other examples would then be:
>
> .module fp=xx
> .module arch=mips_n
> 
> .module fp=32
> .module arch=mips_n
> 
>
> .module fp=xx
> .module arch=mips2
> 
> .module fp=64
> .module arch=mips2
>  (existing behaviour for .set)
>
> .module fp=xx
> .module arch=mips1
> 
> .module fp=64
> .module arch=mips1 
>  (existing behaviour for .set)
>
> This is weird though for the same reasons as you point out. You have to
> know the arch to know what happens to the FP mode. If we just continued
> with 32-bit arch setting fp=32 and 64-bit setting fp=64 then we have a
> problem with something like mips_n where fp=32 would be invalid. I
> really don't know what is best here!

The ".set mips" handling of gp and fp is really there for local changes
to the architecture in a .set push/pop or .set mipsN/mips0.  (And IMO we
the way we do it is a bit of a misfeature, but we have to keep it that
way for compatibility.)

I don't think it should apply to .module though.  Ideally .module should
work in the same way as passing the associated command-line option.

Thanks,
Richard

RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking

[Matthew Fortune]

Richard Sandiford  writes:
> Matthew Fortune  writes:
> >> > With these defaults, the closest supported ABI is used for each
> >> > architecture based on the --with-o32-fp build option. The only one
> >> > I really care about is the middle one as it makes full use of the
> >> > O32 FPXX ABI without a user needing to account for arch
> restrictions.
> >>
> >> Note that --with-* options just insert a canned -mfoo=bar option
> >> under certain conditions, with those conditions being the same
> >> regardless of "bar".
> >> So --with-o32-fp=32 should insert -mfp32 (and nothing else),
> >> --with-o32-
> >> fp=64 should insert -mfp64, etc.
> >>
> >> The rules should therefore be the same for both -mfp and --with-o32-
> fp.
> >> Should:
> >>
> >>   mips-*-gcc -march=mips1 -mfpxx
> >>
> >> generate -mfp32 code too?  It seems counter-intuitive to me.
> >>
> >> I suppose it depends on what you want -mfpxx to mean.  Do you want it
> >> to mean "use the new ABI that is link-compatible with both -mfp32 and
> >> - mfp64"
> >> or do you want it to mean "I don't care what the FR setting is; pick
> >> whatever seems best but be as flexible as possible"?  I'd assumed the
> >> former, in which case using it with an architecture that doesn't
> >> support it should be an error.
> >
> > In the end I do just want fpxx to mean use the new ABI that is
> > link-compatible. I think I have managed to confuse this discussion by
> > not understanding/separating vendor specific specs from generic option
> > handling as you explain later in your email. I only really wish to
> > allow a vendor specific config to infer a suitable default fp option
> > from -march (like -mabi=32 for 32-bit arch and -mabi=n32 for 64-bit
> arch).
> 
> Well, for avoidance of doubt, --with has priority over the vendor-
> specific choices, so really this comes down to what happens when no -mfp
> and --with-o32-fp options are used.

Yes that is what I understood.

> >> If you want to go for tha latter meaning then I think we should be
> >> careful to distinguish it from cases where we really are talking
> >> about the new ABI variant.  E.g. an ELF file has to commit to one of
> >> the three
> >> modes: you shouldn't have to look at the ELF's architecture setting
> >> in order to interpret the FP setting correctly.  And IMO the assembly
> >> code needs to commit to a specific mode too.  What do you think
> >> should happen
> >> for:
> >>
> >>   .module fp=xx
> >>   .module arch=mips_n
> >>
> >> Should the output be FR=X or FR=1?
> >
> > Well, even defining fpxx as simply being another abi variant there are
> > some issues. The current .set arch= options set fp32 for 32-bit
> > architectures and fp64 for 64-bit architectures which means we do have
> > to come up with some definition of how fpxx interacts with this. My
> > current implementation is that, for .set arch, the fp option is only
> > changed if the existing setting is incompatible with the new arch. So
> > carrying that logic to .module means that in the case above then the
> > output would be FPXX. Other examples would then be:
> >
> > .module fp=xx
> > .module arch=mips_n
> > 
> > .module fp=32
> > .module arch=mips_n
> > 
> >
> > .module fp=xx
> > .module arch=mips2
> > 
> > .module fp=64
> > .module arch=mips2
> >  (existing behaviour for .set)
> >
> > .module fp=xx
> > .module arch=mips1
> > 
> > .module fp=64
> > .module arch=mips1
> >  (existing behaviour for .set)
> >
> > This is weird though for the same reasons as you point out. You have
> > to know the arch to know what happens to the FP mode. If we just
> > continued with 32-bit arch setting fp=32 and 64-bit setting fp=64 then
> > we have a problem with something like mips_n where fp=32 would be
> > invalid. I really don't know what is best here!
> 
> The ".set mips" handling of gp and fp is really there for local changes
> to the architecture in a .set push/pop or .set mipsN/mips0.  (And IMO we
> the way we do it is a bit of a misfeature, but we have to keep it that
> way for compatibility.)
> 
> I don't think it should apply to .module though.  Ideally .module should
> work in the same way as passing the associated command-line option.

As it stands I wasn't planning on supporting .module arch= I was just going to 
add .module fp= and leave it at that. The only thing I need to give assembly 
code writers absolute control over is the overall FP mode of the module. I 
don't currently see any real need to increase the control a user has over 
architecture level. If we had .module arch= then having it just set the arch 
ignorant of FP mode seems fine, checking for erroneous combinations would be 
difficult due to some chicken and egg scenarios. Do you think I need to add 
.module arch= if I add .module fp= or can I take the easy option?

Regards,
Matthew