latent issues with stack_ties on ppc ?
Hello,
A question on the stack/frame_tie circuitry for a ppc/V4_abi target, to
check about a potential remaining latent problem in this area.
With gcc 4.3, we had a case where the prologue generation emitted
a sequence like
(insn 191 190 192 9 t.adb:30:8 (set (reg:SI 25 25)
(mem/c:SI (plus:SI (reg:SI 11 11)
(const_int -28 [0xffe4])) [11 S4 A32])) -1 (nil))
...
(insn 199 198 200 9 t.adb:30:8 (set (mem/c:BLK (reg/f:SI 1 1) [11 A8])
(unspec:BLK [
(mem/c:BLK (reg/f:SI 1 1) [11 A8])
(insn 200 199 201 9 t.adb:30:8 (set (reg/f:SI 1 1)
(reg:SI 11 11)) -1 (nil))
insn 199 was a stack_tie intended to prevent the stack pointer restore from
moving prior to the register restores, which failed with sched2 moving both
the tie and the sp restore up, prior to insn 191. My understanding is that
that was allowed by the tie referencing the mem with r1 while the restores
access the frame via r11.
There were many PRs about similar issues, on ppc and other targets,
e.g. 38644, or 44199.
PR 44199 resulted in changes for powerpc, which introduced variations in a
couple of tie insertions. We can, however, still observe epilogue patterns
similar to the above one out of mainline today, e.g.
(note 54 31 55 2 NOTE_INSN_EPILOGUE_BEG)
...
(insn 58 57 59 2 (set (reg:SI 25 25)
(mem/c:SI (plus:SI (reg:SI 11 11)
(const_int -28 [0xffe4])) [6 S4 A8])) im.adb:10 -1
...
(insn 60 59 61 2 (set (mem/c:BLK (reg/f:SI 1 1) [6 A8])
(unspec:BLK [
(mem/c:BLK (reg/f:SI 1 1) [6 A8])
] 5)) im.adb:10 -1
(insn/f 61 60 62 2 (set (reg/f:SI 1 1)
(reg:SI 11 11)) im.adb:10 -1
(expr_list:REG_CFA_DEF_CFA (reg/f:SI 1 1)
(expr_list:REG_CFA_RESTORE (reg/f:SI 31 31)
(expr_list:REG_CFA_RESTORE (reg:SI 25 25)
for the Ada testcase below, at -O2 with a compiler configured for
powerpc-wrs-vxworks.
While I don't quite see what would prevent sched2 to issue the troublesome
reordering, I haven't been able to trigger it so far.
So my question is:
Is there indeed something blocking the tie/sp move up here (new since 4.3) ?
Or do we still have a latent problem in this case ?
Thanks in advance for your feedback,
Olivier
--
with Machine_Code;
function Im (X : Integer) return Integer is
S : String (1 .. X);
pragma Volatile (S);
begin
Machine_Code.Asm
("nop", Clobber => "25", Volatile => True);
return X;
end;
temporarily giving up using Git for GCC MELT
Hello All,
Even with the help of very nice people and of the gcc@ list, I am unable to
use git for GCC MELT with ease. I tried this entire week without success
My only issue is merging the trunk into GCC MELT but since this is something
I am doing several times a week, it makes me temporarily give up the use of
GIT (which I find otherwise very nice).
GCC MELT has an important property: is is almost entirely a strict superset
of the trunk. To be more precise, the only difference between GCC MELT and
the trunk are
* lots of MELT specific files or directories: their name contain melt or
MELT inside.
* significant differences in building procedures that is in configure.ac
and Makefile.{tpl,def} & Makefile.in files (either toplevel source directory
or gcc/ subdirectory). The MELT branch is conceptually only adding things.
The MELT branch building is buggy (for example, make -j don't work, so you
need to do a serial make) and I am trying progressively to improve it, but
moving code out of files and using include features...
* very small differences in the code proper:
a. Several MELT specific options -mostly named -fmelt-* - to
gcc/common.opt
b. The gcc/toplev.c adds call to melt_initialize() & melt_finalize()
Of course, the similarity of MELT with the trunk is one purpose, since MELT
is designed to be compilable as a plugin. Actually, even in the MELT branch,
the MELT propoer code is a quasi- or pseudo- plugin.
Given the above properties of GCC MELT, with the svnmerge tool from
subersion-tools package (in Debian) the merge of trunk into MELT is just
running
svnmerge merge
and then rebuilding to check that everything is ok. Most of the time (that
is, when the trunk did not touch gcc/toplev.c or gcc/common.opt or build
files like Makefile.in...) I'm getting not conflict with that. With git I
always got hundreds of conflict... So I am temporarily giving up using GIT.
Aopparently, git is a very powerful tool, and there is some GCC specific way
to use it which I did not understood. I have no issues using git on small
projects. There are many things I don't understand in git.
By the way, if you happen to be in Paris' region (in France) and have a few
yours to help me face to face mastering GIT for GCC MELT, I would be
grateful. I really need to meet people in person & talk to them face to face
(and I don't have IRC) with my laptop.
Regards.
PS. By the way, git clone-ing the GCC git repository takes a lot of time
from Europe. Perhaps having a daily tar ball of the result of that command
available by ftp would be very nice
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
semantics of attribute const on constructors
Hi, what are the exact semantics of __attribute__((const)), when attached to a C++ class constructor, supposed to be? My expectation was, that, since the ctor has a constructed object as return value, the compiler is free, instead of calling a ctor twice for the case of e.g. Foo a(1); Foo b(1); , to do a memcopy of a to b after the a ctor is done. Instead the result of using __attribute__((const)) is, that GCC feels free to optimize the whole ctor away. Apparently the ctor is treated as a function that returns void. Do you rather want a bug report for the website documenting attribute const, or for how GCC implements it? :-) Cheers, Matthias -- Dipl.-Phys. Matthias Kretz http://compeng.uni-frankfurt.de/index.php?id=mkretz
GIMPLE Question
I have the following code:
foo.hh
==
class A
{
};
class foo
{
A a;
public:
void bar(A & aa);
};
foo.cc
==
#include "foo.hh"
void foo::bar(A & aa)
{
a = aa;
}
However the gimple generated via g++-4.5 -c -fdump-tree-gimple foo.cc
is this:
void foo::bar(A&) (struct foo * const this, struct A & aa)
{
GIMPLE_NOP
}
My question is this, what do I have to do to get the contents of the bar
method? I am working on a plugin that traverses the AST and GIMPLE but
I cannot seem to get the contents of methods similar to this example...
all I get is a GIMPLE_NOP. When the method is a little more complex I
get the proper gimple and all is well but simple methods elude me.
Is there gimple for such a simple method or do I have to delve into the
some other part of the AST in order to get the information I need? Any
hints as to how I would go about doing that?
Cheers,
Kyle
Re: semantics of attribute const on constructors
On Fri, Feb 25, 2011 at 4:19 PM, Matthias Kretz wrote: > Hi, > > what are the exact semantics of __attribute__((const)), when attached to a C++ > class constructor, supposed to be? > > My expectation was, that, since the ctor has a constructed object as return > value, the compiler is free, instead of calling a ctor twice for the case of > e.g. > Foo a(1); > Foo b(1); > , to do a memcopy of a to b after the a ctor is done. > > Instead the result of using __attribute__((const)) is, that GCC feels free to > optimize the whole ctor away. Apparently the ctor is treated as a function > that returns void. If you lie to the compiler weird things will happen ;) > Do you rather want a bug report for the website documenting attribute const, > or for how GCC implements it? :-) None of the two. Richard. > Cheers, > Matthias > > -- > Dipl.-Phys. Matthias Kretz > http://compeng.uni-frankfurt.de/index.php?id=mkretz >
Re: semantics of attribute const on constructors
Hi, On Friday 25 February 2011 16:26:24 Richard Guenther wrote: > On Fri, Feb 25, 2011 at 4:19 PM, Matthias Kretz wrote: > > My expectation was, that, since the ctor has a constructed object as > > return value, the compiler is free, instead of calling a ctor twice for > > the case of e.g. > > Foo a(1); > > Foo b(1); > > , to do a memcopy of a to b after the a ctor is done. > > > > Instead the result of using __attribute__((const)) is, that GCC feels > > free to optimize the whole ctor away. Apparently the ctor is treated as > > a function that returns void. > > If you lie to the compiler weird things will happen ;) I fully understand why it happened. So I imply your answer is that ctors do not have a return value and my expectation, as explained above, is wrong. > > Do you rather want a bug report for the website documenting attribute > > const, or for how GCC implements it? :-) > > None of the two. Ah, but if the semantics are meant to be this way then at least add another warning statement so that nobody else has to do a 2 hour bug-search session like I just did. The website says: "Many functions do not examine any values except their arguments, and have no effects except the return value. Basically this is just slightly more strict class than the pure attribute below, since function is not allowed to read global memory. Note that a function that has pointer arguments and examines the data pointed to must not be declared const. Likewise, a function that calls a non-const function usually must not be const. It does not make sense for a const function to return void." All of these statements hold for my ctor in question: 1. only examines its arguments 2. no effects other than writing to its class members 1b. doesn't read global memory 3. has an implicit pointer argument (this), which points to the memory area that is basically the return value of a ctor. 4. doesn't call any non-const function 5. there's no void anywhere in the function :-P So please change e.g. the last sentence to: "It does not make sense to use const with a function that returns void or with constructors." Regards, Matthias -- Dipl.-Phys. Matthias Kretz http://compeng.uni-frankfurt.de/index.php?id=mkretz
Google Summer of Code 2011
Google Summer of Code 2011 will start accepting applications from mentoring organizations on 28/Feb. We have until 11/Mar to send our application. If you have ideas for projects for this year and/or would want to serve as a mentor, please contact me. Diego.
Re: Google Summer of Code 2011
On Fri, Feb 25, 2011 at 10:56, Diego Novillo wrote: > Google Summer of Code 2011 will start accepting applications from > mentoring organizations on 28/Feb. We have until 11/Mar to send our > application. > > If you have ideas for projects for this year and/or would want to > serve as a mentor, please contact me. I forgot to add. The web site describing this year's program is http://www.google-melange.com/ Diego.
Re: GIMPLE Question
On 25/02/2011 15:20, Kyle Girard wrote:
> foo.hh
> ==
>
> class A
> {
> };
>
> class foo
> {
> A a;
> public:
> void bar(A & aa);
> };
>
>
> foo.cc
> ==
>
> #include "foo.hh"
>
> void foo::bar(A & aa)
> {
> a = aa;
> }
>
>
> However the gimple generated via g++-4.5 -c -fdump-tree-gimple foo.cc
>
> is this:
>
> void foo::bar(A&) (struct foo * const this, struct A & aa)
> {
> GIMPLE_NOP
> }
>
>
> My question is this, what do I have to do to get the contents of the bar
> method?
That *is* the content of the bar method. What exactly do you expect to see
happening when you assign a class with no members? There's nothing to do!
cheers,
DaveK
Re: semantics of attribute const on constructors
On 25/02/2011 16:43, Matthias Kretz wrote: Hi, On Friday 25 February 2011 16:26:24 Richard Guenther wrote: On Fri, Feb 25, 2011 at 4:19 PM, Matthias Kretz wrote: My expectation was, that, since the ctor has a constructed object as return value, the compiler is free, instead of calling a ctor twice for the case of e.g. Foo a(1); Foo b(1); , to do a memcopy of a to b after the a ctor is done. Instead the result of using __attribute__((const)) is, that GCC feels free to optimize the whole ctor away. Apparently the ctor is treated as a function that returns void. If you lie to the compiler weird things will happen ;) I fully understand why it happened. So I imply your answer is that ctors do not have a return value and my expectation, as explained above, is wrong. Do you rather want a bug report for the website documenting attribute const, or for how GCC implements it? :-) None of the two. Ah, but if the semantics are meant to be this way then at least add another warning statement so that nobody else has to do a 2 hour bug-search session like I just did. The website says: "Many functions do not examine any values except their arguments, and have no effects except the return value. Basically this is just slightly more strict class than the pure attribute below, since function is not allowed to read global memory. Note that a function that has pointer arguments and examines the data pointed to must not be declared const. Likewise, a function that calls a non-const function usually must not be const. It does not make sense for a const function to return void." All of these statements hold for my ctor in question: 1. only examines its arguments 2. no effects other than writing to its class members 1b. doesn't read global memory 3. has an implicit pointer argument (this), which points to the memory area that is basically the return value of a ctor. 4. doesn't call any non-const function 5. there's no void anywhere in the function :-P So please change e.g. the last sentence to: "It does not make sense to use const with a function that returns void or with constructors." Regards, Matthias A constructor /does/ take a pointer argument (the implicit "this"), and it (normally) /does/ have side effects - it sets values pointed to be *this. So it can't be __attribute__((const)), as it breaks two of the conditions.
Re: semantics of attribute const on constructors
On 25/02/2011 15:43, Matthias Kretz wrote: > I fully understand why it happened. So I imply your answer is that ctors do > not have a return value and my expectation, as explained above, is wrong. You'd already know if ctors had return values, because you'd have had to be writing return statements in them all along if they did. For chapter and verse, c++ spec (iso/iec 14882) 12.1.10: > No return type (not even void) shall be specified for a constructor. A > return statement in the body of a constructor shall not specify a return > value. [ ... ] No return values there. (You may have been thinking of overloaded operators, that often end with a "return *this" statement.) > The website says: > "Many functions do not examine any values except their arguments, and have no > effects except the return value. Basically this is just slightly more strict > class than the pure attribute below, since function is not allowed to read > global memory. > Note that a function that has pointer arguments and examines the data pointed > to must not be declared const. Likewise, a function that calls a non-const > function usually must not be const. It does not make sense for a const > function to return void." > > All of these statements hold for my ctor in question: > 1. only examines its arguments > 2. no effects other than writing to its class members So, there you go. The this object in a constructor is not the "return value", so writing the members counts as "effects except the return value". Basically, making your ctor const told the compiler that it would not write to any of the class object's members! cheers, DaveK
[google] Merged trunk into google/integration
Merged as of rev 170439. Tested on x86_64. Diego.
Re: semantics of attribute const on constructors
Hi, I don't generally disagree, that GCC does the correct thing here. I'm completely satisfied if you don't change GCC. I'm saying that the way I thought about const + ctor seems logical (if you are not a compiler developer at least :-) ). Regardless of how well defined "return value" is in the standards, to me as C++ developer the ctor acts as a function that takes some input and leaves as output a constructed object. Therefore, please be so nice to non-compiler developers and add a few words about ctors (possibly about C++ member functions in general, since they all have an implicit pointer argument) to the const attribute docs. How about this patch to the docs? - Note that a function that has pointer arguments and examines the data pointed to must not be declared const. + Note that a function that has pointer arguments and examines the data pointed to must not be declared const. This includes all C++ member functions, including constructors, which have an implicit this-pointer argument. On Friday 25 February 2011 17:42:40 Dave Korn wrote: > On 25/02/2011 15:43, Matthias Kretz wrote: > > I fully understand why it happened. So I imply your answer is that ctors > > do not have a return value and my expectation, as explained above, is > > wrong. > > You'd already know if ctors had return values, because you'd have had to > be writing return statements in them all along if they did. For chapter > and verse, c++ spec (iso/iec 14882) 12.1.10: > > > No return type (not even void) shall be specified for a constructor. A > > return statement in the body of a constructor shall not specify a return > > value. [ ... ] > > No return values there. (You may have been thinking of overloaded > operators, that often end with a "return *this" statement.) > > > The website says: > > "Many functions do not examine any values except their arguments, and > > have no effects except the return value. Basically this is just slightly > > more strict class than the pure attribute below, since function is not > > allowed to read global memory. > > Note that a function that has pointer arguments and examines the data > > pointed to must not be declared const. Likewise, a function that calls a > > non-const function usually must not be const. It does not make sense for > > a const function to return void." > > > > All of these statements hold for my ctor in question: > > 1. only examines its arguments > > 2. no effects other than writing to its class members > > So, there you go. The this object in a constructor is not the "return > value", so writing the members counts as "effects except the return value". > Basically, making your ctor const told the compiler that it would not write > to any of the class object's members! > > cheers, > DaveK Regards, Matthias -- Dipl.-Phys. Matthias Kretz http://compeng.uni-frankfurt.de/index.php?id=mkretz
Re: semantics of attribute const on constructors
On 25 February 2011 17:05, Matthias Kretz wrote: > > I'm saying that the way I thought about const + ctor seems logical (if you are > not a compiler developer at least :-) ). Regardless of how well defined > "return value" is in the standards, to me as C++ developer the ctor acts as a > function that takes some input and leaves as output a constructed object. But it definitely doesn't *return* that object, any more than the destructor does.
Re: semantics of attribute const on constructors
Hi, On Friday 25 February 2011 19:37:27 Jonathan Wakely wrote: > On 25 February 2011 17:05, Matthias Kretz wrote: > > I'm saying that the way I thought about const + ctor seems logical (if > > you are not a compiler developer at least :-) ). Regardless of how well > > defined "return value" is in the standards, to me as C++ developer the > > ctor acts as a function that takes some input and leaves as output a > > constructed object. > > But it definitely doesn't *return* that object, any more than the > destructor does. Yes. Now, in light of the clear definition of "return value" my previous text looks stupid. I'd write it differently now - but with the same content. Take it as what the average C++ developer will take away from the docs (I actually consider myself above average - though not in terms of how fluent I am in correct C++ terminology) ... BTW, my notion of return value comes from looking at the generated asm. It certainly is a return value for the code I'm writing. While I'm convinced that you can derive the behavior of const + ctor in GCC from the docs, I'm neither convinced that other developers won't have the same problem, nor that it wouldn't make sense to be able to declare const ctors. In my case I'm working around it by having the ctor call a const C-function whose return value initializes the data. This should, hopefully, result in the same effect. Another aside: The classes I'm working on have their member data not in memory in many places (basically wrapping an SSE/AVX register) and through inlining the this pointer completely disappears. That's the level I'm thinking on. What does the destructor now have to do with it? A dtor either has side effects (e.g. free) or it is not required. Regards, Matthias -- Dipl.-Phys. Matthias Kretz http://compeng.uni-frankfurt.de/index.php?id=mkretz
Re: GIMPLE Question
> That *is* the content of the bar method. What exactly do you expect to see
> happening when you assign a class with no members? There's nothing to do!
I was hoping to see the assignment. My example might have been a little
too simple. Here's a slightly more complex example:
foo.hh
class A
{
public:
void yay(){};
};
class foo
{
A a;
public:
void bar(A & aa);
void wik();
};
foo.cc
#include "foo.hh"
void foo::bar(A & aa)
{
a = aa;
}
void foo::wik()
{
a.yay();
}
foo.cc.004t.gimple
void foo::wik() (struct foo * const this)
{
struct A * D.1731;
D.1731 = &this->a;
A::yay (D.1731);
}
void A::yay() (struct A * const this)
{
GIMPLE_NOP
}
void foo::bar(A&) (struct foo * const this, struct A & aa)
{
GIMPLE_NOP
}
Looking at the gimple output there is no way to see that 'a' was
assigned in bar(). So that it can be used in wik(). Am I
misunderstanding something shouldn't there be a way to see the
assignment in bar? Do I have to parse the expression statement or are
things already optimized away and there is no way to get the information
that I seek.
Cheers,
Kyle
Re: GIMPLE Question
On Fri, Feb 25, 2011 at 11:21 AM, Kyle Girard wrote:
>
>> That *is* the content of the bar method. What exactly do you expect to see
>> happening when you assign a class with no members? There's nothing to do!
>
>
> I was hoping to see the assignment. My example might have been a little
> too simple. Here's a slightly more complex example:
>
> foo.hh
>
> class A
> {
> public:
> void yay(){};
> };
A is still an empty class, try adding "int a;" and you will see some code there.
Thanks,
Andrew Pinski
Re: gcc-4.5/4.4: Bug in .subreg1 pass?
Paul Koning schrieb: On Feb 24, 2011, at 12:46 PM, Eric Botcazou wrote: Maybe the misunderstanding occurs when the mode of the subreg is less than word_size? It would certainly make sense that a subreg write of less than word_size leaves the bits undefined. ie, if word_size is SImode and we had a write to (subreg:HI (reg:SI) 0) Then the upper bits are left undefined. Contrast that to the same RTL, but word_size is HImode (subreg:HI (reg:SI) 0) Would leave the upper bits untouched. That's the conventional wisdom I think. Sub-word and word-sized subregs don't behave the same, in particular when they are on the LHS of an assignment. That's certainly what the manual says. I still don't understand. The manual says: http://gcc.gnu.org/onlinedocs/gccint/Regs-and-Memory.html#Regs-and-Memory When storing to a normal subreg that is smaller than a word, the other bits of the referenced word are usually left in an undefined state. This laxity makes it easier to generate efficient code for such instructions. To represent an instruction that preserves all the bits outside of those in the subreg, use strict_low_part or zero_extract around the subreg. What does "word" mean here? Is it a 32-bit entity or is it according to word_mode which is QImode for avr? In the latter case, all code generated by subreg lowering and RTL lowering (which expands DI operation to bulk of (set (subreg:QI (DI)) as avr backend does not have DI-insns) is fine and I will have to dig in IRA for PR45291, PR46779 and maybe others. In the first case all code that RTL lowering produces for 64-bit stuff would be incorrect which is hard to imagine... Some lines after that, internals give an example for HI subregs of PSI: > If "UNITS_PER_WORD <= 2" then these two subregs: > (subreg:HI (reg:PSI 0) 0) > (subreg:HI (reg:PSI 0) 2) > represent independent 2-byte accesses that together span the whole of > "(reg:PSI 0)". Storing to the first subreg does not affect the value > of the second, and vice versa. So the same should be true for QI-subregs of scalar modes if UNITS_PER_WORT = 1. Right? Georg-Johann
Re: GIMPLE Question
On 25/02/2011 19:21, Kyle Girard wrote:
> I was hoping to see the assignment.
> Looking at the gimple output there is no way to see that 'a' was
> assigned in bar(). So that it can be used in wik(). Am I
> misunderstanding something shouldn't there be a way to see the
> assignment in bar? Do I have to parse the expression statement or are
> things already optimized away and there is no way to get the information
> that I seek.
Ah, right. Yes, the stuff you see at the GIMPLE level has already been
substantially processed compared to the original AST - operations decomposed,
constants folded, that kind of thing. For instance if (like Andrew suggests)
we add a "int x;" declaration in class A from your original example, we get:
> void foo::bar(A&) (struct foo * const this, struct A & aa)
> {
> this->a = MEM[(const struct A &)aa];
> }
You probably need to look earlier than GIMPLE time. What plugin event are
you hooking?
cheers,
DaveK
Re: GIMPLE Question
On Fri, Feb 25, 2011 at 11:33:58AM -0800, Andrew Pinski wrote:
> On Fri, Feb 25, 2011 at 11:21 AM, Kyle Girard wrote:
> >
> >> That *is* the content of the bar method. What exactly do you expect to
> >> see
> >> happening when you assign a class with no members? There's nothing to do!
> >
> >
> > I was hoping to see the assignment. My example might have been a little
> > too simple. Here's a slightly more complex example:
> >
> > foo.hh
> >
> > class A
> > {
> > public:
> > void yay(){};
> > };
>
> A is still an empty class, try adding "int a;" and you will see some code
> there.
The fact that passing an empty class has zero cost is used quite a bit in
the design of the standard library to generate efficient specialized
templates. The empty objects are just used to select the correct
overloaded form.
Re: GIMPLE Question
On Fri, 2011-02-25 at 19:57 +, Dave Korn wrote:
> On 25/02/2011 19:21, Kyle Girard wrote:
>
> > I was hoping to see the assignment.
>
> > Looking at the gimple output there is no way to see that 'a' was
> > assigned in bar(). So that it can be used in wik(). Am I
> > misunderstanding something shouldn't there be a way to see the
> > assignment in bar? Do I have to parse the expression statement or are
> > things already optimized away and there is no way to get the information
> > that I seek.
>
> Ah, right. Yes, the stuff you see at the GIMPLE level has already been
> substantially processed compared to the original AST - operations decomposed,
> constants folded, that kind of thing. For instance if (like Andrew suggests)
> we add a "int x;" declaration in class A from your original example, we get:
>
> > void foo::bar(A&) (struct foo * const this, struct A & aa)
> > {
> > this->a = MEM[(const struct A &)aa];
> > }
>
Ok that's starting to make a little bit more sense...
> You probably need to look earlier than GIMPLE time. What plugin event are
> you hooking?
Currently, I try to get the earliest GIMPLE possible by using creating
my own pass like this
struct register_pass_info pass_info;
pass_info.pass = &myPass;
pass_info.reference_pass_name = all_lowering_passes->name;
pass_info.ref_pass_instance_number = 0;
pass_info.pos_op = PASS_POS_INSERT_AFTER;
register_callback(pluginName, PLUGIN_PASS_MANAGER_SETUP, NULL,
&pass_info);
Which, if I understand correctly gets me in before any major
optimization happens to the GIMPLE. But by the sounds of it I will need
to go earlier somehow for some methods/functions. Is it possible to be
an earlier pass and still have proper GIMPLE?
or can i hook in earlier and sort of put my own artificial GIMPLE in
somehow? If that is possible how would I know when the to fake the
GIMPLE and when not to?
Cheers,
Kyle
Re: gcc-4.5/4.4: Bug in .subreg1 pass?
> What does "word" mean here? Is it a 32-bit entity or is it according to > word_mode which is QImode for avr? The latter, it is machine-dependent. > So the same should be true for QI-subregs of scalar modes if > UNITS_PER_WORT = 1. Right? Right. -- Eric Botcazou
Re: gcc-4.5/4.4: Bug in .subreg1 pass?
Eric Botcazou schrieb: What does "word" mean here? Is it a 32-bit entity or is it according to word_mode which is QImode for avr? The latter, it is machine-dependent. So the same should be true for QI-subregs of scalar modes if UNITS_PER_WORT = 1. Right? Right. Thanks for that definite clarification. Internals are sometimes confusing, incomplete or outdated, so I prefere to reassure me here. Thanks again :-) Georg-Johann
gcc restores wrong stack pointer value?
m32c-elf, gcc.dg/torture/stackalign/nested-1 at -O0, produces this code: _bar.1229: enter #0 pushm r1,r2,r3,a0,a1 ; end of prologue mov.l a0,r3r1 add.l #-66,sp stc sp,a1 . . . ldc a1,sp ; start of epilogue popmr1,r2,r3,a0,a1 exitd Note that the $sp restored just before the epilogue is NOT the value of $sp at the end of the prologue, so the wrong registers get popped. (the exitd works because it uses the frame pointer). EXIT_IGNORE_STACK is set to 0. Is this expected behavior? Do I need to do some magic in my epilogue to further "fix" the stack pointer? Note: the add.l is not part of the prologue; the "end of prologue" comment is a volatile unspec; the pushm is the last thing emitted by the prolog function. The '#0' on the enter is the stack adjustment the prologue does.
-flto / -flto-partition=none question on ia64-hp-hpux11.23
I am looking at an lto bug on ia64-hp-hpux11.23. If I compile g++.dg/torture/pr33572.C with -flto on this platform I get: ld: Unsatisfied symbol "__gcc_personality_v0" in file /var/tmp//ccYlpGzO.ltrans0.ltrans.o 1 errors. collect2: ld returned 1 exit status (This is using the HP linker which I do for all my GCC builds.) If I add -flto-partition=none to the link, then everything works fine. I notice that the =none option fo -flto-partition does not seem to be documented in invoke.texi, which only covers 1to1 and balanced so I am not sure what it means (put everything in one object?). In both cases if I look at the output of the linker I see an undef of __gcc_personality_v0 in the object file created by compiling pr33572.C and a definition that should resolve that use in libstdc++.so. libstdc++.so is searched in both cases and __gcc_personality_v0 is found in both cases so I don't understand why I am getting the error in the standard -flto case. Does anyone have any ideas on what I should look at to understand this problem? I get this on a few other -flto programs, but not on all of them. Steve Ellcey s...@cup.hp.com
