Advertisement in the GCC mirrors list, again

[niXman]

Hi,

mirrors.webhostinggeeks.com/gcc/

Help with gcc-plugin (Traverse all loops inside function)

[Aditya K]

I started with one of the test cases in the plugin testsuite "def_plugin.c". 
Pasted the code for convenience.
I want to traverse all the loops in a function.

Maybe use, loops_for_fn (DECL_STRUCT_FUNCTION (fndef)), but this does not seem 
to work.


/* Callback function to invoke after GCC finishes a function definition. */

void plugin_finish_parse_function (void *event_data, void *data)
{
  tree fndef = (tree) event_data;
  //struct loops *l  = loops_for_fn (DECL_STRUCT_FUNCTION (fndef));
  warning (0, G_("Finish fndef %s"),
           IDENTIFIER_POINTER (DECL_NAME (fndef)));
}

int
plugin_init (struct plugin_name_args *plugin_info,
             struct plugin_gcc_version *version)
{
  const char *plugin_name = plugin_info->base_name;

  register_callback (plugin_name, PLUGIN_START_PARSE_FUNCTION,
                     plugin_start_parse_function, NULL);

  register_callback (plugin_name, PLUGIN_FINISH_PARSE_FUNCTION,
                     plugin_finish_parse_function, NULL);
  return 0;
}

Thanks,
-Aditya


  

Re: Cost and Benefit Allocation for moving the expression above the conditional.

[Richard Biener]

On Sun, Sep 6, 2015 at 2:46 PM, Ajit Kumar Agarwal
 wrote:
> All:
>
> The cost and benefit associated for moving a given expression above 
> conditional  are the important factors for the performance boost.
>
> Considering the above, the cost and benefit calculation can be derived based 
> on below.
>
> For a given conditional entry point 'n', the benefit path 'p'  are the sub 
> paths that passes through 'n' and available and anticipatable at the 
> conditional
> Entry n.
>
> For a given conditional entry point 'n', the cost path 'p' are the sub paths 
> that passes through 'n' and are unavailable and un-anticipatable at the
> Conditional entry n.
>
> Thus the Benefit =  summation of the frequency of all the benefit paths as 
> given above.
> Cost = Summation of the frequency of all the cost paths as given above.
>
> Thus the movement of expression above the conditional can be enabled if the 
> Benefit > Cost as calculated above.
>
> The derivation above can be extended to Loop Invariant code motion.
>
> The above benefit and the cost derivation can be extended to the following 
> based on number of DEFs and use.
>
> Benefit = Summation of the frequency of all the benefit paths + summation of 
> (number  of defs * latency of store instruction)  of all benefit paths
> +summation of ( number of uses * latency of load instruction ) of all benefit 
> paths +  -  Summation of  ( Number of moves * latency of move instructions)
> Of all benefit paths.
>
> Cost =  Benefit = Summation of the frequency of all the cost paths + 
> summation of (number  of defs * latency of store instruction)  of all cost 
> paths
> +summation of ( number of uses * latency of load instruction ) of all cost 
> paths-  Summation of  ( Number of moves * latency of move instructions)
> Of all cost paths
>
> The movement of the expressions above the condition and can be extended  to 
> LICM if the benefit is greater than cost.
>
> The above is feasible and quite efficient for the cost and Benefit allocation 
> for control flow code motion. This  above cost  somewhat equivalent to
> Cost of the Live range priority and  selection of coloring the live ranges 
> based on priority.

PRE kind-of considers this "locally" for each insert location, but the
data-flow driven solution doesn't know the "path" an
expression was coming from so I don't see how we could implement this
more "global" scheme.

Richard.

>
> Thanks & Regards
> Ajit

Re: reload question about unmet constraints

[Ulrich Weigand]

Jim Wilson wrote:
> On Mon, Sep 14, 2015 at 11:05 PM, DJ Delorie  wrote:
> > As a test, I added this API.  It seems to work.  I suppose there could
> > be a better API where we determine if a constrain matches various
> > memory spaces, then compare with the memory space of the operand, but
> > I can't prove that's sufficiently flexible for all targets that
> > support memory spaces.  Heck, I'm not even sure what to call the
> > macro, and 
> > "TARGET_IS_THIS_MEMORY_ADDRESS_RELOADABLE_TO_MATCH_THIS_CONTRAINT_P()"
> > is a little long ;-)
> >
> > What do we think of this direction?
> 
> We already have define_constraint and define_memory_constraint.  We
> could perhaps add a define_special_memory_constraint that returns
> CT_SPECIAL_MEMORY which mostly operates like CT_MEMORY, except that it
> doesn't assume any MEM can be reloaded to match.

But the only difference between define_memory_constraint and a plain
define_constraint is just that define_memory_constraint guarantees
that any memory operand can be made valid by reloading the address
into a base register ...

If the set of operands accepted by a constraint does *not* have that
property, it must not be defined via define_memory_constraint, and
you should simply use define_constraint instead.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Re: reload question about unmet constraints

[Jim Wilson]

On Tue, Sep 15, 2015 at 7:42 AM, Ulrich Weigand  wrote:
> But the only difference between define_memory_constraint and a plain
> define_constraint is just that define_memory_constraint guarantees
> that any memory operand can be made valid by reloading the address
> into a base register ...
>
> If the set of operands accepted by a constraint does *not* have that
> property, it must not be defined via define_memory_constraint, and
> you should simply use define_constraint instead.

An invalid near mem can be converted to a valid near mem by reloading
its address into a base reg.  An invalid far mem can be converted to a
valid far mem by reloading its address into a base reg.  But one can't
convert a near mem to a far mem by reloading the address, nor can one
convert a far mem to a near mem by reloading its address.  So we need
another dimension to the validity testing here, besides the question
of whether the address can be reloaded, there is the question of
whether it is in the right address space.  Though I don't think the
rl78 is actually using address spaces, and it isn't clear if that
would help.

Jim

Re: reload question about unmet constraints

[Ulrich Weigand]

Jim Wilson wrote:
> On Tue, Sep 15, 2015 at 7:42 AM, Ulrich Weigand  wrote:
> > But the only difference between define_memory_constraint and a plain
> > define_constraint is just that define_memory_constraint guarantees
> > that any memory operand can be made valid by reloading the address
> > into a base register ...
> >
> > If the set of operands accepted by a constraint does *not* have that
> > property, it must not be defined via define_memory_constraint, and
> > you should simply use define_constraint instead.
> 
> An invalid near mem can be converted to a valid near mem by reloading
> its address into a base reg.  An invalid far mem can be converted to a
> valid far mem by reloading its address into a base reg.  But one can't
> convert a near mem to a far mem by reloading the address, nor can one
> convert a far mem to a near mem by reloading its address.  So we need
> another dimension to the validity testing here, besides the question
> of whether the address can be reloaded, there is the question of
> whether it is in the right address space.  Though I don't think the
> rl78 is actually using address spaces, and it isn't clear if that
> would help.

I see.  Is it correct then to say that reload will never be able to
change a near mem into a far mem or vice versa?  If that is true, there
doesn't appear to be any real benefit to having both near and far mem
operations as *alternatives* to the same insn pattern.

In that case, you might be able to fix the bug by splitting the
offending insns into two patterns, one only handling near mems
and one handling one far mems, where the near/far-ness of the mem
is verified by the *predicate* and not the constraints.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

RE: [AArch64] A question about Cortex-A57 pipeline description

[Evandro Menezes]

Indeed, we observed some problems with scheduling which we believe has more
to do with the scheduling algorithm than with the model DFA, as we said in
https://gcc.gnu.org/ml/gcc/2015-09/msg00118.html

Cheers,

-- 
Evandro Menezes  Austin, TX

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Nikolai Bozhenov
> Sent: Monday, September 14, 2015 2:28
> To: James Greenhalgh
> Cc: gcc@gcc.gnu.org
> Subject: Re: [AArch64] A question about Cortex-A57 pipeline description
> 
> Thanks for the reply! I see you point. Indeed, I've also seen cases where
the
> load pipeline was overused at the beginning of a basic block, whereas at
the
> end the code got stuck with a bunch of stores and no other instructions to
> run in parallel. And indeed, relaxing the restrictions makes things even
> worse in some cases. Anyway, I don't believe it's the best we can do, I'm
> going to have a closer look at the scheduler and see what can be done to
> improve the situation.
> 
> Nikolai
> 
> 
> On 09/11/2015 07:21 PM, James Greenhalgh wrote:
> > On Fri, Sep 11, 2015 at 04:31:37PM +0100, Nikolai Bozhenov wrote:
> >> Hi!
> >>
> >> Recently I got somewhat confused by Cortex-A57 pipeline description
> >> in GCC and I would be grateful if you could help me understand a few
> >> unclear points.
> > Sure,
> >
> >> Particularly I am interested in how memory operations (loads/stores)
> >> are scheduled. It seems that according to the cortex-a57.md file,
> >> firstly, two memory operations may never be scheduled at the same
> >> cycle and, secondly, two loads may never be scheduled at two
consecutive
> cycles:
> >>
> >>   ;; 5.  Two pipelines for load and store operations: LS1, LS2. The
> most
> >>   ;; valuable thing we can do is force a structural hazard to
> split
> >>   ;; up loads/stores.
> >>
> >>   (define_cpu_unit "ca57_ls_issue" "cortex_a57")
> >>   (define_cpu_unit "ca57_ldr, ca57_str" "cortex_a57")
> >>   (define_reservation "ca57_load_model" "ca57_ls_issue,ca57_ldr*2")
> >>   (define_reservation "ca57_store_model"
> >> "ca57_ls_issue,ca57_str")
> >>
> >> However, the Cortex-A57 Software Optimization Guide states that the
> >> core is able to execute one load operation and one store operation
> >> every cycle. And that agrees with my experiments. Indeed, a loop
> >> consisting of 10 loads, 10 stores and several arithmetic operations
> >> takes on average about 10 cycles per iteration, provided that the
> instructions are intermixed properly.
> >>
> >> So, what is the purpose of additional restrictions imposed on the
> >> scheduler in cortex-a57.md file? It doesn't look like an error.
> >> Rather, it looks like a deliberate decision.
> > When designing the model for the Cortex-A57 processor, I was primarily
> > trying to build a model which would increase the blend of utilized
> > pipelines on each cycle across a range of benchmarks, rather than to
> > accurately reflect the constraints listed in the Cortex-A57 Software
> > Optimisation Guide [1].
> >
> > My reasoning here is that the Cortex-A57 is a high-performance
> > processor, and an accurate model would be infeasible to build. Because
> > of this, it is unlikely that the model in GCC will be representative
> > of the true state of the processor, and consequently GCC may make
> > decisions which result in an instruction stream which would bias
> > towards one execution pipeline. In particular, given a less
> > restrictive model, GCC will try to hoist more loads to be earlier in
> > the basic block, which can result in less good utilization of the other
> execution pipelines.
> >
> > In my experiments, I found this model to be more beneficial across a
> > range of benchmarks than a model with the additional restrictions I
imposed
> relaxed.
> > I'd be happy to consider counter-examples where this modeling produces
> > suboptimal results - and where the changes you suggest are sufficient
> > to resolve the issue.
> >
> > Thanks,
> > James
> >
> > ---
> > [1]: Cortex-A57 Software Optimisation Guide
> >
> >
>
http://infocenter.arm.com/help/topic/com.arm.doc.uan0015a/cortex_a57_softwar
e
> _optimisation_guide_external.pdf
> >

Re: reload question about unmet constraints

[Jim Wilson]

On Tue, Sep 15, 2015 at 8:53 AM, Ulrich Weigand  wrote:
> Jim Wilson wrote:
> In that case, you might be able to fix the bug by splitting the
> offending insns into two patterns, one only handling near mems
> and one handling one far mems, where the near/far-ness of the mem
> is verified by the *predicate* and not the constraints.

That is how it works currently.  He was trying to optimize a case that
involved mixed near and far mems and hence couldn't use a predicate in
that case.

Jim

Re: reload question about unmet constraints

[DJ Delorie]

> I see.  Is it correct then to say that reload will never be able to
> change a near mem into a far mem or vice versa?  If that is true, there
> doesn't appear to be any real benefit to having both near and far mem
> operations as *alternatives* to the same insn pattern.

The RL78 has a segment register, much like the x86.  The segment
register allows you to have a 20-bit address instead of a 16-bit
address.  However, due to details of the port, you can only have *one*
segment register override per operation, even if it applies to more
than one (identical) operand.  So, you can add two near pointers, but
you can't add two different far pointers, but you can add something to
a far pointer (i.e. x += 5).

> In that case, you might be able to fix the bug by splitting the
> offending insns into two patterns, one only handling near mems
> and one handling one far mems, where the near/far-ness of the mem
> is verified by the *predicate* and not the constraints.

But this means that when reload needs to, it moves far mems into
registers, which changes which insn is matched...  It also adds a
*lot* of new patterns, since any of the three operands can be far, and
'0' constraints on far are allowed also - and most insns allow far
this way, so could be up to seven times as many patterns.

You can see why I'd rather not do that :-)

Git conversion: disposition of old branches and tags

[Jason Merrill]

There are lots of ancient branches and tags in the SVN repository that 
are no longer interesting, and it would be nice not to have them 
cluttering up the lists and default fetch set.


The options I see for each branch or tag are:
1) Keep them at the same place.
2) Move them to a subdirectory like "dead", as was sometimes done in SVN.
3) Delete them.
4) Move them out of refs/{heads,tags}, perhaps into refs/namespaces/dead 
or refs/namespaces/archive.


For release tags and active branches, #1 is obviously the right choice.

I don't think #2 is very useful.

I think #3 is the right choice for the *merge* tags: they are just 
artifacts of the difficulty of SVN merges, and I think we should discard 
them.


For most old branches and tags, I like #4; that takes them out of the 
set that is fetched by default, but keeps the history on the server.


Make sense?

Jason

Re: Git conversion: disposition of old branches and tags

[Joseph Myers]

On Tue, 15 Sep 2015, Jason Merrill wrote:

> There are lots of ancient branches and tags in the SVN repository that are no
> longer interesting, and it would be nice not to have them cluttering up the
> lists and default fetch set.
> 
> The options I see for each branch or tag are:
> 1) Keep them at the same place.
> 2) Move them to a subdirectory like "dead", as was sometimes done in SVN.
> 3) Delete them.
> 4) Move them out of refs/{heads,tags}, perhaps into refs/namespaces/dead or
> refs/namespaces/archive.

I think putting things outside refs/heads and refs/tags is unduly 
confusing and it's best to keep all the history in the default fetch set; 
having large numbers of branches and tags is simply a consequence of 
having a long-lived project.  That is, #1 or #2.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Git conversion: disposition of old branches and tags

[Florian Weimer]

* Jason Merrill:

> There are lots of ancient branches and tags in the SVN repository that
> are no longer interesting, and it would be nice not to have them
> cluttering up the lists and default fetch set.

Just one minor comment: Due to the way Git branches work, this
decision can be deferred to some extent (existing clones will keep
renamed or removed branches if they were part of the initial clone).

> 1) Keep them at the same place.

So 1) is probably the best initial choice.

> 3) Delete them.

Unlike Subversion branch deletion, Git branch deletion is permanent,
so this might not be the best option.

dejagnu version update?

[Mike Stump]

On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
>> Maybe GCC-6 can bump the required
>> dejagnu version to allow for getting rid of all these superfluous
>> load_gcc_lib? *blink* :)
> I'd support that as a direction.
> 
> Certainly dropping the 2001 version from our website in favor of 1.5 (which 
> is what I'm using anyway) would be a step forward.

So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to 1.5.  I 
don’t know of any reason to not update and just require 1.5 at this point.  I’m 
not a fan of feature chasing dejagnu, but an update every 2-4 years isn’t 
unreasonable.

So, let’s do it this way…  Any serious and compelling reason to not update to 
1.5?  If none, let’s update to 1.5 in another week or two, if no serious and 
compelling reasons not to.

My general plan is, slow cycle updates on dejagnu, maybe every 2 years.  LTS 
style releases should have the version in it before the requirement is updated. 
 I take this approach as I think this should be the maximal change rate of 
things like make, gcc, g++, ld, if possible.

Re: dejagnu version update?

[David Malcolm]

On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
> On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
> >> Maybe GCC-6 can bump the required
> >> dejagnu version to allow for getting rid of all these superfluous
> >> load_gcc_lib? *blink* :)
> > I'd support that as a direction.
> > 
> > Certainly dropping the 2001 version from our website in favor of 1.5
> (which is what I'm using anyway) would be a step forward.
> 
> So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
> 1.5.  I don’t know of any reason to not update and just require 1.5 at
> this point.  I’m not a fan of feature chasing dejagnu, but an update
> every 2-4 years isn’t unreasonable.

FWIW, I believe RHEL 6 is at dejagnu-1.4.4   I don't know whether or not
that's an issue here.

> So, let’s do it this way…  Any serious and compelling reason to not
> update to 1.5?  If none, let’s update to 1.5 in another week or two,
> if no serious and compelling reasons not to.
> 
> My general plan is, slow cycle updates on dejagnu, maybe every 2
> years.  LTS style releases should have the version in it before the
> requirement is updated.  I take this approach as I think this should
> be the maximal change rate of things like make, gcc, g++, ld, if
> possible.

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 15, 2015 7:39:39 PM GMT+02:00, Mike Stump  
wrote:
>On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
>>> Maybe GCC-6 can bump the required
>>> dejagnu version to allow for getting rid of all these superfluous
>>> load_gcc_lib? *blink* :)
>> I'd support that as a direction.
>> 
>> Certainly dropping the 2001 version from our website in favor of 1.5
>(which is what I'm using anyway) would be a step forward.
>
>So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
>1.5.  I don’t know of any reason to not update and just require 1.5 at
>this point.  I’m not a fan of feature chasing dejagnu, but an update
>every 2-4 years isn’t unreasonable.
>
>So, let’s do it this way…  Any serious and compelling reason to not
>update to 1.5?  If none, let’s update to 1.5 in another week or two, if
>no serious and compelling reasons not to.
>
>My general plan is, slow cycle updates on dejagnu, maybe every 2 years.
>LTS style releases should have the version in it before the requirement
>is updated.  I take this approach as I think this should be the maximal
>change rate of things like make, gcc, g++, ld, if possible.

Yea, although this means that 1.5.3 (a Version with the libdirs tweak) being 
just 5 months old will have to wait another bump, I fear. For my part going to 
plain 1.5 is useless WRT the load_lib situation. I see no value in 
conditionalizing simplified libdir handling on a lucky user with recentish 
stuff so i'm just waiting another 2 or 4 years for this very minor cleanup.

Cheers,

Re: Live range Analysis based on tree representations

[Aaron Sawdey]

On Sat, 2015-09-12 at 18:45 +, Ajit Kumar Agarwal wrote:
> 
> 
> -Original Message-
> From: Aaron Sawdey [mailto:acsaw...@linux.vnet.ibm.com] 
> Sent: Friday, September 04, 2015 11:51 PM
> To: Ajit Kumar Agarwal
> Cc: Jeff Law; vmaka...@redhat.com; Richard Biener; gcc@gcc.gnu.org; Vinod 
> Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
> Subject: Re: Live range Analysis based on tree representations
> 
> On Thu, 2015-09-03 at 15:22 +, Ajit Kumar Agarwal wrote:
> > 
> > 
> > -Original Message-
> > From: Aaron Sawdey [mailto:acsaw...@linux.vnet.ibm.com]
> > Sent: Wednesday, September 02, 2015 8:23 PM
> > To: Ajit Kumar Agarwal
> > Cc: Jeff Law; vmaka...@redhat.com; Richard Biener; gcc@gcc.gnu.org; 
> > Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju 
> > Mekala
> > Subject: Re: Live range Analysis based on tree representations
> > 
> > On Tue, 2015-09-01 at 17:56 +, Ajit Kumar Agarwal wrote:
> > > All:
> > > 
> > > The Live ranges info on tree SSA representation is important step towards 
> > > the SSA based code motion optimizations.
> > > As the code motion optimization based on the SSA representation 
> > > effects the register pressure and reasons for performance Bottleneck.
> > > 
> > > I am proposing the Live range Analysis based on the SSA 
> > > representation. The Live range analysis traverses the dominator Tree.
> > > The SSA and phi variables are represented based on dominance frontier 
> > > info and the SSA representation reflects The dominance info. Based on 
> > > such dominance info Live range Overlapping Analysis can be derived.
> > > 
> > > Variable V intersects W if Vdef dominates the Wdef. The variable v 
> > > intersects at point p if Vdef dominates P and Wdef Dominates the P. 
> > > If Vdef dominates Wdef and Wdef dominates Udef , then the Vdef 
> > > dominates Udef and thus Live range Of V intersect W and live range W 
> > > intersect U, thus the live range V intersects the U. Such dominance 
> > > info can be used to Represent the Overlapping Live range Analysis and the 
> > > register pressure is derived from Overlapping Live ranges based On the 
> > > dominator info inherited from the SSA representation. The SSA 
> > > representation is derived based on dominance Frontier and the traversal 
> > > of dominator tree based on SSA can derive the Overlapping Live ranges.
> > > 
> > > The above Overlapping Live range info can be used to derive the 
> > > register pressure and the optimization based out of tree Representation 
> > > can use the above overlapping live ranges to take register pressure into 
> > > account.
> > 
> > >>Ajit,
> >   >>I did a prototype of this kind of analysis at one point last year to 
> > see if it could help improve inlining decisions in LTO. Basically I did 
> > >>exactly what you suggest and computed the number of overlapping SSA live 
> > ranges and used that as a proxy for register pressure. It >>did appear to 
> > be able to help in some circumstances but the real solution is to improve 
> > register allocation so it doesn't fall down when >>register pressure gets 
> > high.
> > 
> > Aaron:
> > Would you mind in explaining on what circumstances it helps and when 
> > it won't.  The Live ranges on SSA representation forms chordal Graphs 
> > that might have the different colorability requirements than the real 
> > register allocator. This may not give exact register pressure compared 
> > to  register allocator as register allocator is  further down the 
> > optimization and the code generation pipeline  but forms the basis of 
> > optimization based on SSA that effects the register pressure.
> >  
> > >>The code is in a branch called lto-pressure.
> > 
> > Thanks. I would like to see the code.
> 
> Ajit,
> >>  The branch is here: svn://gcc.gnu.org/svn/gcc/branches/lto-pressure
> >>The analysis is in ipa-inline.c; if you search for "pressure" you'll find 
> >>the code.
> 
> >>The live ranges in SSA are certainly different than what the register 
> >>allocator is going to see, but it's what we have to work with at the point 
> >>where the >>inlining decisions are made, which is why I was looking at it. 
> >>My hope was that it would be a reasonable proxy for downstream register 
> >>pressure. 
> 
> >>I went and did this after seeing a particular situation in bzip2 where a 
> >>bunch of inlining done by LTO sent register pressure up a lot and resulted 
> >>in a >>measureable increase in loads/stores due to extra spill code. 
> >>Functions that are called in only one place and not externally visible will 
> >>be inlined regardless of >>their size. There is one function in bzip2 that 
> >>has particularly complex control and inlining this into another non-trivial 
> >>function caused all the excess spill code.
> 
> >>Setting limits on "inline functions called only once" did work, i.e.
> >>inhibited the particular inlining that I wanted to eliminate; it just 
> >>didn't help enough to justify th

Re: dejagnu version update?

[Jeff Law]

On 09/15/2015 01:23 PM, Bernhard Reutner-Fischer wrote:

On September 15, 2015 7:39:39 PM GMT+02:00, Mike Stump
 wrote:

On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:

Maybe GCC-6 can bump the required dejagnu version to allow for
getting rid of all these superfluous load_gcc_lib? *blink* :)

I'd support that as a direction.

Certainly dropping the 2001 version from our website in favor of
1.5

(which is what I'm using anyway) would be a step forward.

So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website
to 1.5.  I don’t know of any reason to not update and just require
1.5 at this point.  I’m not a fan of feature chasing dejagnu, but
an update every 2-4 years isn’t unreasonable.

So, let’s do it this way…  Any serious and compelling reason to
not update to 1.5?  If none, let’s update to 1.5 in another week or
two, if no serious and compelling reasons not to.

My general plan is, slow cycle updates on dejagnu, maybe every 2
years. LTS style releases should have the version in it before the
requirement is updated.  I take this approach as I think this
should be the maximal change rate of things like make, gcc, g++,
ld, if possible.


Yea, although this means that 1.5.3 (a Version with the libdirs
tweak) being just 5 months old will have to wait another bump, I
fear. For my part going to plain 1.5 is useless WRT the load_lib
situation. I see no value in conditionalizing simplified libdir
handling on a lucky user with recentish stuff so i'm just waiting
another 2 or 4 years for this very minor cleanup.
Given we haven't updated the dejagnu reqs since ~2001, I think stepping 
forward would be appropriate and I'd support moving all the way to 1.5.3 
with the expectation that we'll be on a cadence of no faster than 2 
years going forward.


jeff

Re: dejagnu version update?

[Jeff Law]

On 09/15/2015 01:21 PM, David Malcolm wrote:

On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:

On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:

Maybe GCC-6 can bump the required
dejagnu version to allow for getting rid of all these superfluous
load_gcc_lib? *blink* :)

I'd support that as a direction.

Certainly dropping the 2001 version from our website in favor of 1.5

(which is what I'm using anyway) would be a step forward.

So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
1.5.  I don’t know of any reason to not update and just require 1.5 at
this point.  I’m not a fan of feature chasing dejagnu, but an update
every 2-4 years isn’t unreasonable.


FWIW, I believe RHEL 6 is at dejagnu-1.4.4   I don't know whether or not
that's an issue here.
I'd consider it a non-issue.  Folks that want to do GCC development on 
RHEL 6 are probably few and far between and can probably update dejagnu 
if need be ;-)


If ubuntu, fedora, debian current releases were stuck at 1.4, then it'd 
be a bigger issue.


jeff

Re: RFC: Support x86 interrupt and exception handlers

[H.J. Lu]

On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu  wrote:
> The interrupt and exception handlers are called by x86 processors.  X86
> hardware puts information on stack and calls the handler.  The
> requirements are
>
> 1. Both interrupt and exception handlers must use the 'IRET' instruction,
> instead of the 'RET' instruction, to return from the handlers.
> 2. All registers are callee-saved in interrupt and exception handlers.
> 3. The difference between interrupt and exception handlers is the
> exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
> instruction.
>
> The design goals of interrupt and exception handlers for x86 processors
> are:
>
> 1. No new calling convention in compiler.
> 2. Support both 32-bit and 64-bit modes.
> 3. Flexible for compilers to optimize.
> 4. Easy to use by programmers.
>
> To implement interrupt and exception handlers for x86 processors, a
> compiler should support:
>
> 1. void * __builtin_ia32_interrupt_data (void)

I got a feedback on the name of this builtin function.  Since
it also works for 64-bit,  we should avoid ia32 in its name.
We'd like to change it to

void * __builtin_interrupt_data (void)

Any comments?

> This function returns a pointer to interrupt or exception data pushed
> onto the stack by processor.
>
> The __builtin_frame_address builtin isn't suitable for interrupt and
> exception handlers since it returns the stack frame address on the
> callee side and compiler may generate a new stack frame for stack
> alignment.
>
> 2. 'interrupt' attribute
>
> Use this attribute to indicate that the specified void function without
> arguments is an interrupt handler.  The compiler generates function entry
> and exit sequences suitable for use in an interrupt handler when this
> attribute is present.  The 'IRET' instruction, instead of the
> 'RET' instruction, is used to return from interrupt handlers.  All
> registers, except for the EFLAGS register which is restored by the
> 'IRET' instruction, are preserved by the compiler.  The red zone
> isn't supported in an interrupt handler; that is an interrupt
> handler can't access stack beyond the current stack pointer.
>
> You can use the builtin '__builtin_ia32_interrupt_data' function to access
> data pushed onto the stack by processor:
>
> void
> f () __attribute__ ((interrupt))
> {
>   void *p = __builtin_ia32_interrupt_data ();
>   ...
> }
>
> 3. 'exception' attribute
>
> Use 'exception' instead of 'interrupt' for handlers intended to be
> used for 'exception' (i.e. those that must pop 'ERROR_CODE' off the
> stack before the 'IRET' instruction):
>
> void
> f () __attribute__ ((exception))
> {
>   void *p = __builtin_ia32_interrupt_data ();
>   ...
> }
>
> Any comments, suggestions?
>
> Thanks.
>
>
> --
> H.J.



-- 
H.J.

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 15, 2015 10:05:27 PM GMT+02:00, Jeff Law  wrote:
>On 09/15/2015 01:21 PM, David Malcolm wrote:
>> On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
>>> On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
> Maybe GCC-6 can bump the required
> dejagnu version to allow for getting rid of all these superfluous
> load_gcc_lib? *blink* :)
 I'd support that as a direction.

 Certainly dropping the 2001 version from our website in favor of
>1.5
>>> (which is what I'm using anyway) would be a step forward.
>>>
>>> So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
>>> 1.5.  I don’t know of any reason to not update and just require 1.5
>at
>>> this point.  I’m not a fan of feature chasing dejagnu, but an update
>>> every 2-4 years isn’t unreasonable.
>>
>> FWIW, I believe RHEL 6 is at dejagnu-1.4.4   I don't know whether or
>not
>> that's an issue here.
>I'd consider it a non-issue.  Folks that want to do GCC development on 
>RHEL 6 are probably few and far between and can probably update dejagnu
>
>if need be ;-)
>
>If ubuntu, fedora, debian current releases were stuck at 1.4, then it'd
>
>be a bigger issue.

Debian sid has 1.5.3 fwiw, so I assume Debian 9 will have that too. Not sure if 
we can get it into Debian 8, I'm not intimately familiar with the policy. If 
OTOH GCC-6 requires it then that's probably a strong argument to let it bubble 
down to Debian 8 if need be.
Widespread other buildsystems should pose no problem, dunno about the big 
non-debian distros in this respect.

Thanks,

Re: Offer of help with move to git

[Andrew Cagney]

On 24 August 2015 at 09:40, Tom Tromey  wrote:
> Eric> In the mean time, I'm enclosing a contributor map that will need to be
> Eric> filled in whoever does the conversion.  The right sides should become
> Eric> full names and preferred email addresses.
>
> It's probably worth starting with the map I used when converting gdb.
> There is a lot of overlap between the sets of contributors.
>
> See the file "Total-merged-user-map" here:
>
> https://github.com/tromey/gdb-git-migration

The process used by that conversion was overly simplistic.  It
resulted in git attributions like:

commit 90e2fa9c54de04a52fd5980238a1087b9291750f
Author: Andrew Cagney 
Date:   Mon May 11 21:21:47 2009 +

2009-05-11  Andrew Cagney  

* MAINTAINERS: Orphan ppc.

commit 8e70166dc52cf82a61e0a414f364f3ff7c45dfa7
Author: Andrew Cagney 
Date:   Tue Aug 9 16:35:45 2005 +

2005-08-09  Andrew Cagney  

* linux-nat.h (linux_proc_xfer_memory): Change type of "myaddr" a
"gdb_byte" pointer.

which are bordering on offensive (You'll note I have a personal
assignment on file).

Using @gcc; or, as ESR suggested, a linear map would certainly be
better (but even then there's no guarantee that developers weren't
deliberately using two addresses.  For instance, one to identify paid,
and one to identify voluntary work).

Andrew

RE: RFC: Support x86 interrupt and exception handlers

[Matthew Fortune]

H.J. Lu  writes:
> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu  wrote:
> > The interrupt and exception handlers are called by x86 processors.  X86
> > hardware puts information on stack and calls the handler.  The
> > requirements are
> >
> > 1. Both interrupt and exception handlers must use the 'IRET' instruction,
> > instead of the 'RET' instruction, to return from the handlers.
> > 2. All registers are callee-saved in interrupt and exception handlers.
> > 3. The difference between interrupt and exception handlers is the
> > exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
> > instruction.
> >
> > The design goals of interrupt and exception handlers for x86 processors
> > are:
> >
> > 1. No new calling convention in compiler.
> > 2. Support both 32-bit and 64-bit modes.
> > 3. Flexible for compilers to optimize.
> > 4. Easy to use by programmers.
> >
> > To implement interrupt and exception handlers for x86 processors, a
> > compiler should support:
> >
> > 1. void * __builtin_ia32_interrupt_data (void)
> 
> I got a feedback on the name of this builtin function.  Since
> it also works for 64-bit,  we should avoid ia32 in its name.
> We'd like to change it to
> 
> void * __builtin_interrupt_data (void)
> 
> Any comments?

For what it's worth, this seems like a good plan to me. I don't know x86
but how many variations of interrupt and exception handling mechanisms
are there? If there are lots then you may want to make it clear which
subset of them you intend to support. I just added a few more variations
of interrupt handlers to MIPS and it got complicated quite quickly.

I think I remember someone asking about interrupt handler support for
x86 some time ago and the answer then was that there were too many
variants to make it useful.

Thanks,
Matthew

> 
> > This function returns a pointer to interrupt or exception data pushed
> > onto the stack by processor.
> >
> > The __builtin_frame_address builtin isn't suitable for interrupt and
> > exception handlers since it returns the stack frame address on the
> > callee side and compiler may generate a new stack frame for stack
> > alignment.
> >
> > 2. 'interrupt' attribute
> >
> > Use this attribute to indicate that the specified void function without
> > arguments is an interrupt handler.  The compiler generates function entry
> > and exit sequences suitable for use in an interrupt handler when this
> > attribute is present.  The 'IRET' instruction, instead of the
> > 'RET' instruction, is used to return from interrupt handlers.  All
> > registers, except for the EFLAGS register which is restored by the
> > 'IRET' instruction, are preserved by the compiler.  The red zone
> > isn't supported in an interrupt handler; that is an interrupt
> > handler can't access stack beyond the current stack pointer.
> >
> > You can use the builtin '__builtin_ia32_interrupt_data' function to access
> > data pushed onto the stack by processor:
> >
> > void
> > f () __attribute__ ((interrupt))
> > {
> >   void *p = __builtin_ia32_interrupt_data ();
> >   ...
> > }
> >
> > 3. 'exception' attribute
> >
> > Use 'exception' instead of 'interrupt' for handlers intended to be
> > used for 'exception' (i.e. those that must pop 'ERROR_CODE' off the
> > stack before the 'IRET' instruction):
> >
> > void
> > f () __attribute__ ((exception))
> > {
> >   void *p = __builtin_ia32_interrupt_data ();
> >   ...
> > }
> >
> > Any comments, suggestions?
> >
> > Thanks.
> >
> >
> > --
> > H.J.
> 
> 
> 
> --
> H.J.

Re: RFC: Support x86 interrupt and exception handlers

[H.J. Lu]

On Tue, Sep 15, 2015 at 2:45 PM, Matthew Fortune
 wrote:
> H.J. Lu  writes:
>> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu  wrote:
>> > The interrupt and exception handlers are called by x86 processors.  X86
>> > hardware puts information on stack and calls the handler.  The
>> > requirements are
>> >
>> > 1. Both interrupt and exception handlers must use the 'IRET' instruction,
>> > instead of the 'RET' instruction, to return from the handlers.
>> > 2. All registers are callee-saved in interrupt and exception handlers.
>> > 3. The difference between interrupt and exception handlers is the
>> > exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
>> > instruction.
>> >
>> > The design goals of interrupt and exception handlers for x86 processors
>> > are:
>> >
>> > 1. No new calling convention in compiler.
>> > 2. Support both 32-bit and 64-bit modes.
>> > 3. Flexible for compilers to optimize.
>> > 4. Easy to use by programmers.
>> >
>> > To implement interrupt and exception handlers for x86 processors, a
>> > compiler should support:
>> >
>> > 1. void * __builtin_ia32_interrupt_data (void)
>>
>> I got a feedback on the name of this builtin function.  Since
>> it also works for 64-bit,  we should avoid ia32 in its name.
>> We'd like to change it to
>>
>> void * __builtin_interrupt_data (void)
>>
>> Any comments?
>
> For what it's worth, this seems like a good plan to me. I don't know x86
> but how many variations of interrupt and exception handling mechanisms
> are there? If there are lots then you may want to make it clear which
> subset of them you intend to support. I just added a few more variations
> of interrupt handlers to MIPS and it got complicated quite quickly.
>
> I think I remember someone asking about interrupt handler support for
> x86 some time ago and the answer then was that there were too many
> variants to make it useful.

In my proposal, there are only 2 handlers: interrupt and exception.
__builtin_interrupt_data is provided to programmers to implement
different variants of those handlers.

>
>>
>> > This function returns a pointer to interrupt or exception data pushed
>> > onto the stack by processor.
>> >
>> > The __builtin_frame_address builtin isn't suitable for interrupt and
>> > exception handlers since it returns the stack frame address on the
>> > callee side and compiler may generate a new stack frame for stack
>> > alignment.
>> >
>> > 2. 'interrupt' attribute
>> >
>> > Use this attribute to indicate that the specified void function without
>> > arguments is an interrupt handler.  The compiler generates function entry
>> > and exit sequences suitable for use in an interrupt handler when this
>> > attribute is present.  The 'IRET' instruction, instead of the
>> > 'RET' instruction, is used to return from interrupt handlers.  All
>> > registers, except for the EFLAGS register which is restored by the
>> > 'IRET' instruction, are preserved by the compiler.  The red zone
>> > isn't supported in an interrupt handler; that is an interrupt
>> > handler can't access stack beyond the current stack pointer.
>> >
>> > You can use the builtin '__builtin_ia32_interrupt_data' function to access
>> > data pushed onto the stack by processor:
>> >
>> > void
>> > f () __attribute__ ((interrupt))
>> > {
>> >   void *p = __builtin_ia32_interrupt_data ();
>> >   ...
>> > }
>> >
>> > 3. 'exception' attribute
>> >
>> > Use 'exception' instead of 'interrupt' for handlers intended to be
>> > used for 'exception' (i.e. those that must pop 'ERROR_CODE' off the
>> > stack before the 'IRET' instruction):
>> >
>> > void
>> > f () __attribute__ ((exception))
>> > {
>> >   void *p = __builtin_ia32_interrupt_data ();
>> >   ...
>> > }
>> >
>> > Any comments, suggestions?
>> >
>> > Thanks.
>> >
>> >
>> > --
>> > H.J.
>>
>>
>>
>> --
>> H.J.



-- 
H.J.

gcc-5-20150915 is now available

[gccadmin]

Snapshot gcc-5-20150915 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150915/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 227812

You'll find:

 gcc-5-20150915.tar.bz2   Complete GCC

  MD5=309bc66445d273db578f6bdc45b22e63
  SHA1=743e161bc98afa7450fa44e8b8dbe148be430fd4

Diffs from 5-20150908 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: dejagnu version update?

[Mike Stump]

On Sep 15, 2015, at 1:04 PM, Jeff Law  wrote:
> Given we haven't updated the dejagnu reqs since ~2001, I think stepping 
> forward would be appropriate and I'd support moving all the way to 1.5.3 with 
> the expectation that we'll be on a cadence of no faster than 2 years going 
> forward.

So, I actually picked 1.5, not at random, but because RHEL 7 has 1.5.1 and 
because ubuntu LTS has 1.5.  The point was for people to get the software for 
free via their normal update mechanisms.  We could go beyond 1.5 if we had a 
compelling need.  I just don’t see the need.  The software presently works with 
1.4.4 and there aren’t any changes that require anything newer.  If the ubuntu 
people and the RHEL people can push 1.5.3 into their update chains, that would 
remove these two reasons to hold back at 1.5.  MacPorts has 1.5.3 already, not 
sure about brew.

If someone wanted to do something major, I’m fine with on demand dejagnu 
release and a bump of gcc and even the release branch to match it.

I don’t have a strong desire to not update past 1.5, if people really would 
like to.  Just a general, would be nice not to have to.

Re: Repository for the conversion machinery

[Andrew Cagney]

On 28 August 2015 at 13:24, Jeff Law  wrote:
> cagney = Andrew Cagney 

cag...@gnu.org?

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

>> cagney = Andrew Cagney 
> cag...@gnu.org?

Good point.  The email identities of people change over time; forcing
a single arbitrary one to label all contributions is at best imprecise
and at worse a miscrediting.  (This is one way in which the impersonal
use...@gcc.gnu.org aliases work better.)

- FChE

Re: Help with gcc-plugin (Traverse all loops inside function)

[Mikhail Maltsev]

On 09/15/2015 03:38 PM, Aditya K wrote:
> I started with one of the test cases in the plugin testsuite "def_plugin.c". 
> Pasted the code for convenience.
> I want to traverse all the loops in a function.
> 
> Maybe use, loops_for_fn (DECL_STRUCT_FUNCTION (fndef)), but this does not 
> seem to work.
> 
> 
> /* Callback function to invoke after GCC finishes a function definition. */
I guess, loop structure is initialized much later within the optimization
pipeline. I.e., PLUGIN_FINISH_PARSE_FUNCTION is invoked before all optimizers,
and (natural) loops are discovered by the "loopinit" pass.

Perhaps, you could try registering a pass using

register_callback (..., PLUGIN_PASS_MANAGER_SETUP, ...)

and make it run within pass_tree_loop (see gcc/passes.def for details). You
should also specify 'PROP_loops' in 'properties_required' of your 'pass_data'
structure. Then 'loops_for_fn' should work.

'selfassign.c' is a good example of a plugin which creates an optimization pass
(and 'dumb_plugin.c' is a good minimal example).

-- 
Regards,
Mikhail Maltsev