Workshop on GCC for Research in Embedded and Parallel Systems
Acronymed GREPS (... just what you were looking for), is to be held on September 16 in Brasov, Romania, co-located with PACT. We'd like to bring this workshop to your attention; the submission site is now open until July 24, after the upcoming GCC Developers' Summit. For more details see http://sysrun.haifa.il.ibm.com/hrl/greps2007/ Thanks, Albert and Ayal.
Re: A reload inheritance bug
Mark Mitchell wrote: Bernd Schmidt wrote: Mark Shinwell wrote: Do you think it should be the case that, at the point below, _any_ reload with reg_rtx corresponding to a hard register should have the relevant bit set in reload_spill_index? I think so. I'm attaching a patch below. It appears to have no effect on all code I've tried - does it fix your test case? Mark, did you get a chance to try Bernd's patch? This does indeed fix the test case. I'll do full test runs for cross to ARM on mainline with this patch applied. Thanks (and sorry for the delay), Mark
LTO reader support for MEMORY_PARTITION_TAG
Kenny --
I tried to get the simplest C program containing a function:
void f() {}
to go through LTO today, but the LTO reader says:
./empty-function.o:0: internal compiler error: in lto_static_init_local,
at lto-tree-flags.def:747
Apparently, this is because the static set-up in lto_static_init_local
doesn't handle MEMORY_PARTITION_TAG (and perhaps other new tree nodes
added after the original LTO branch).
For reference, this is how I compiled the file:
./xgcc -B./ -flto -funit-at-a-time -g -c empty-function.c
./lto1 empty-function.o
Would you be able to take a look at that? I would like to be able to
begin pushing forward on getting small functions to go through the compiler.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: LTO reader support for MEMORY_PARTITION_TAG
Mark Mitchell wrote:
> Kenny --
>
> I tried to get the simplest C program containing a function:
>
> void f() {}
>
> to go through LTO today, but the LTO reader says:
>
> ./empty-function.o:0: internal compiler error: in lto_static_init_local,
> at lto-tree-flags.def:747
>
> Apparently, this is because the static set-up in lto_static_init_local
> doesn't handle MEMORY_PARTITION_TAG (and perhaps other new tree nodes
> added after the original LTO branch).
>
> For reference, this is how I compiled the file:
>
> ./xgcc -B./ -flto -funit-at-a-time -g -c empty-function.c
> ./lto1 empty-function.o
>
> Would you be able to take a look at that? I would like to be able to
> begin pushing forward on getting small functions to go through the compiler.
>
> Thanks,
>
>
this does not surprise me at all.
my first pass was just a take no prisoners lets get the compile time
errors out.
now that we can compile, i will start looking inside today.
kenny
Re: Type-punning
Thanks for the answers!
> > Why? Won't the following work?
> >
> > void setNaN(float &v) {
> > union { float f; int i; } t;
> > t.i = 0x7f81;
> > v = t.f;
> > }
> >
> As far as I know, this is guaranteed to work with GCC. But it is not kosher
> according to language standards, so other compilers might dislike it. On the
> other hand, other compilers are not guaranteed to optimize the call to
> "memcpy" out either.
Thinking about this setNaN trick, why is it not kosher? It seems
completely OK to me (too bad that I missed this "trick").
Note that my problem is not the unnecessary type-punning warning (I could
live with that), but miscompiled code because of the too strict rule that
GCC uses. Maybe GCC shouldn't optimize around invalid type-punnings?
Geza
Re: Type-punning
On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote: Maybe GCC shouldn't optimize around invalid type-punnings? That is what -fno-strict-aliasing is for. Also GCC has done this since 3.0.0 (and also 2.95 and 2.95.1 and then in 2.95.2 it was changed back while most of the free source world fixes their code). Thanks, Andrew Pinski
[tuples/LTO] RFC: houghts on auto-generating GS_* data structures
I chatted briefly with Ken today about the reader/writer being implemented for LTO. One of the difficulties in keeping the reader/writer up-to-date is the evolving IL data structures. Whenever these change, the reader must be adapted to the new format. So, while the reader/writer is fairly straightforward and mechanical, it's a pain to have to keep changing it as new IL elements are added, or existing ones are modified. The idea, then, is to have the IL data structures defined in http://gcc.gnu.org/wiki/tuples to be in a .h file auto-generated from some template. I'm slightly tempted to consider that this would be too much abstraction, but we do change the IL from time to time and according to Ken, changing the reader/writer is somewhat of a pain. Given that we already have other autogenerated .h/.c files, I guess we could use some of the existing functionality. But, first, I'd like to know what folks think about this. Would it be generally useful for us to have the IL data structures auto-generated this way? I can see the benefits in the reader/writer. But also, we are going to have to re-implement the reader/writer when we move GIMPLE out of the tree data structures. OTOH, we will probably change them, add new codes and having them autogenerated may have other advantages. Thoughts? Thanks.
Re: Extending RTL expansion and CG with a new operation
kerneltest.c:22: error: unrecognizable insn: (jump_insn 26 25 29 3 (set (pc) (create_body_after (cre (reg:DI 75) (const_int 0 [0x0])) (label_ref 13) (pc))) -1 (nil) (nil)) kerneltest.c:22: internal compiler error: in extract_insn, at recog.c:2096 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Find a pattern that is close to this one in your md file ( i.e. the define_insn that you think should match this pattern, assuming such a define_insn exists in your md file) and then try to check the reason for recog crashing. IMO, the predicate may not be passing. regards, Pranav
Re: Type-punning
On Tue, 26 Jun 2007, Andrew Pinski wrote:
> On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
> > Maybe GCC shouldn't optimize around invalid type-punnings?
>
> That is what -fno-strict-aliasing is for.
> Also GCC has done this since 3.0.0 (and also 2.95 and 2.95.1 and then
> in 2.95.2 it was changed back while most of the free source world
> fixes their code).
Let me elaborate. If the compiler can detect invalid type-punning,
then shouldn't optimize. For example,
void foo(int *a, float *b) {
// here, access to a and b can be optimized, as the compiler
supposedly doesn't know whether a and b point to the same address
}
but:
void foo(float *a) {
int *b = (int*)a; // type-punning warning
// here, access to a and b shouldn't be optimized, as the compiler
knows that a and b point to the same address
}
Is this reasonable?
Geza
Re: Type-punning
On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
Let me elaborate. If the compiler can detect invalid type-punning,
Not really.
void foo(float *a) {
int *b = (int*)a; // type-punning warning
}
This is actually valid if we don't access both a and b and also the
original type is int.
Is this reasonable?
Not really, see above. Aliasing is a hard problem to solve in
generic. So there are stuff like type based aliasing to help out the
solver. And in the case of GCC, it helps out more than other
compilers.
-- Pinski
Re: LTO reader support for MEMORY_PARTITION_TAG
Mark Mitchell wrote:
> Kenny --
>
> I tried to get the simplest C program containing a function:
>
> void f() {}
>
> to go through LTO today, but the LTO reader says:
>
> ./empty-function.o:0: internal compiler error: in lto_static_init_local,
> at lto-tree-flags.def:747
>
> Apparently, this is because the static set-up in lto_static_init_local
> doesn't handle MEMORY_PARTITION_TAG (and perhaps other new tree nodes
> added after the original LTO branch).
>
> For reference, this is how I compiled the file:
>
> ./xgcc -B./ -flto -funit-at-a-time -g -c empty-function.c
> ./lto1 empty-function.o
>
> Would you be able to take a look at that? I would like to be able to
> begin pushing forward on getting small functions to go through the compiler.
>
> Thanks,
>
>
2007-06-26 Kenneth Zadeck <[EMAIL PROTECTED]>
* lto-read (make_new_block): Initialize the stmt_list.
(lto_static_init_local): Add debugging for missing codes.
2007-06-26 Kenneth Zadeck <[EMAIL PROTECTED]>
* lto-tree-flags.def (tcc_gimple_stmt): New TREE_CLASS.
(GIMPLE_MODIFY_STMT, MEMORY_PARTITION_TAG, VEC_WIDEN_MULT_HI_EXPR,
VEC_WIDEN_MULT_LO_EXPR, VEC_UNPACK_HI_EXPR,
VEC_UNPACK_LO_EXPR, VEC_UNPACK_FLOAT_HI_EXPR,
VEC_UNPACK_FLOAT_LO_EXPR, VEC_PACK_TRUNC_EXPR,
VEC_PACK_SAT_EXPR, VEC_PACK_FIX_TRUNC_EXPR,
VEC_EXTRACT_EVEN_EXPR, VEC_EXTRACT_ODD_EXPR,
VEC_INTERLEAVE_HIGH_EXPR, VEC_INTERLEAVE_LOW_EXPR): New
TREE_EXPRs.
There is no representation that this at all works, it now just does not
blow up on mark's trivial test case.
Further testing will happen tonight and tomorrow.
Kenny
Committed as revision 126044.
Re: Type-punning
Herman Geza wrote:
void foo(float *a) {
int *b = (int*)a; // type-punning warning
// here, access to a and b shouldn't be optimized, as the compiler
knows that a and b point to the same address
}
Is this reasonable?
Even if it were trivial to implement, I would vote against it, because
it would encourage people to write non-compliant code.
In terms of compilation time, it is not reasonable: the standard is
clear about this so that compilers can optimize based on declared types,
without having to perform overly complex (and expensive) alias analysis.
For the corner case where you have non-compliant code that breaks with
-fstrict-aliasing and is much slower with -fno-strict-aliasing, and
which you cannot modify, I think you are on your own. You could in
principle write a pass that flags all the possible references (including
possible aliases) to potentially type-punned addresses. Then you would
have to make sure that this information is understood by the relevant
optimization passes, and that it is preserved across different
representations, i.e., from GIMPLE to RTL. All this work just to fight
the standard :).
Re: How to use GCC testsuite..?
Venkatesan Jeevanandam <[EMAIL PROTECTED]> wrote on
26/06/2007 09:26:18:
> Hi,
>
> I have been given a set of cross-compiler binaries (like arch-gcc,
> arch-as, arch-ld, arch-ar, arch-gdb, etc.,).
> How can i test "arch-gcc" cross-compiler binary using GCC testsuite ?
Do you have an access to such "arch" machine?
The running itself should be done on the target ("arch") machine.
AFAIK, if you don't have such machine, you won't be able to run all the
"need-to-be-executed" tests.
Only the tests that not suppose to run will be tested (like
compilation-only tests).
If you do have such machine, you need to compile on the host (current)
machine and run the binaries remotely.
That can be done by:
1. Write in your .shrc/.bashrc/...: setenv/export DEJAGNU
/home/<$USER>/etc/site.exp
2. Write in /home/<$USER>/etc/site.exp:
append boards_dir "/home/<$USER>/etc/boards"
case "$target_triplet" in {
{ "arch*-*-*" } { set target_list { } }
}
3. Create a file /home/<$USER>/etc/boards/ and write
in it:
load_generic_config "unix" (or anything else...)
set_board_info hostname ""
set_board_info username
set_board_info rsh_prog /usr/bin/ssh (or anything else...)
set_board_info rcp_prog /usr/bin/scp (or anything else...)
Now, actually, you can run the testsuite (as usual, with "make -k check",
or similar command).
In case you have a promt for a passphrase every time you logon to the
target machine, you'll need to type the password for each test.
That is very annoying.
In order to solve that you can use ssa-agent:
1. Type: ssh-keygen -t rsa
2. Type:eval `/usr/bin/ssh-agent -s`
3. Type: /usr/bin/ssh-add < /dev/null
4. copy your ~/.ssh/id_rsa.pub file (generated in the above process) to the
file ~/.ssh/authorized_keys on the machine(s) you wish to be able to access
without a password.
Now you can run "make check" "as usual".
HTH. Good luck,
Tehila.
>
> i have downloaded and extracted gcc-testsuite.x.y.tar.gz. I have also
> installed dejagnu, TCL and expect for testing the cross-compiler with
> gcc testsuite.
>
> Thank you.
>
> Regards
> Venkat
> --
> Venkatesan Jeevanandam <[EMAIL PROTECTED]>
>
>
> DISCLAIMER:
> This message (including attachment if any) is confidential and may
> be privileged. Before opening attachments please check them for
> viruses and defects. MindTree Consulting Limited (MindTree) will not
> be responsible for any viruses or defects or any forwarded
> attachments emanating either from within MindTree or outside. If you
> have received this message by mistake please notify the sender by
> return e-mail and delete this message from your system. Any
> unauthorized use or dissemination of this message in whole or in
> part is strictly prohibited.Please note that e-mails are susceptible
> to change and MindTree shall not be liable for any improper,
> untimely or incomplete transmission.
> E-mail may contain viruses. Before opening attachments please check
> them for viruses and defects. While MindTree Consulting Limited
> (MindTree) has put in place checks to minimize the risks, MindTree
> will not be responsible for any viruses or defects or any forwarded
> attachments emanating either from within MindTree or outside.
Re: Type-punning
On Tue, 26 Jun 2007, Silvius Rus wrote:
> Herman Geza wrote:
> > void foo(float *a) {
> > int *b = (int*)a; // type-punning warning
> >
> > // here, access to a and b shouldn't be optimized, as the compiler
> > knows that a and b point to the same address
> > }
> >
> > Is this reasonable?
> >
> Even if it were trivial to implement, I would vote against it, because it
> would encourage people to write non-compliant code.
Agreed, if it results in non-compilant code. I have problems with
aliasing when GCC (I think) incorrectly treats types different, but
they're the same. For example, I have:
struct Point {
float x, y, z;
};
struct Vector {
float x, y, z;
Point &asPoint() {
return reinterpret_cast(*this);
}
};
Point and Vector have the same layout, but GCC treats them different when
it does aliasing analysis. I have problems when I use Vector::asPoint.
I use asPoint very trivially, it is very easy to detect (for a human)
that references point to the same address. Like
void doSomething(Point p) {
// do something with p
}
void fv() {
Point a, b;
// initialize a & b
doSomething((a-b).asPoint()); // a-b results in a Vector
}
Here, there's a bad compilation (I think) at the call of doSomething.
I solved my problem with
struct Vector {
Point toPoint() {
return Point(x, y, z);
}
};
GCC optimizes this as well, but I use other compilers which don't. It is
not a big issue, I just wanted to know some background behind the warning
:) Thanks for your responses.
Geza
Re: Type-punning
Herman Geza wrote:
aliasing when GCC (I think) incorrectly treats types different, but
they're the same. For example, I have:
struct Point {
float x, y, z;
};
struct Vector {
float x, y, z;
Point &asPoint() {
return reinterpret_cast(*this);
}
};
Point and Vector have the same layout, but GCC treats them different when
it does aliasing analysis. I have problems when I use Vector::asPoint.
I also think this case should not be flagged. I have seen similar usage
in network programming. Did it actually result in bad code or was it
just the warning that bothered you?
:) Thanks for your responses.
You're welcome.
Silvius
Help on testsuite failures, only with optimization & bootstrap
After the dataflow merge (and after doing a couple of other patches that
were needed just to boostrap GCC on IA64 HP-UX), I am still getting some
failures in the GCC testsuite and am hoping for some advise / help on
figuring out what is going on.
A bunch of tests like the following one:
void __attribute__ ((__noinline__)) foo (int xf) {}
int main() { foo (1); return 0; }
Are failing because the generate the following warning:
$ obj_gcc/gcc/cc1 -quiet -O2 x.c
x.c:2: warning: inline function 'foo' given attribute noinline
Now, the problem here is, of course, that foo was no declared to be
inline and the warning should not be happening. If I recompile the GCC
file c-decl.c with -O2 -fno-tree-dominator-opts (instead of just -O2)
then the resulting GCC will not generate the warning message. But so
far I haven't been able to look at the tree dump files and see where
things are going wrong. It doesn't help that the dominator pass gets
run 3 times and I am not sure which one is causing the problem.
Unfortunately, I am only seeing this on IA64 HP-UX. It does not happen
on IA64 Linux.
Does anyone have any advice / ideas / recommendations on how to debug
this problem?
Steve Ellcey
[EMAIL PROTECTED]
Re: Type-punning
On 6/26/07, Silvius Rus <[EMAIL PROTECTED]> wrote: I also think this case should not be flagged. I have seen similar usage in network programming. Did it actually result in bad code or was it just the warning that bothered you? This case is valid only if you go back to original type of Vector. Sorry but the C++ standard says even if two structs have the same layout, the types are different even for aliasing. Thanks, Andrew Pinski
Re: [tuples/LTO] RFC: houghts on auto-generating GS_* data structures
Diego Novillo <[EMAIL PROTECTED]> writes: > But, first, I'd like to know what folks think about this. Would it be > generally useful for us to have the IL data structures auto-generated > this way? I can see the benefits in the reader/writer. But also, we > are going to have to re-implement the reader/writer when we move GIMPLE > out of the tree data structures. OTOH, we will probably change them, > add new codes and having them autogenerated may have other advantages. If we can use mmap to read the IL--which I personally think is going to be a requirement for speed during the LTO phase--then this issue does not necessarily arise. Rather than see work on this, I personally would prefer to see work toward developing an IL which can be read using mmap (possibly with pointer swizzling during the write phase, which is less time critical). If it turns out that auto-generation is still useful during the write phase, I have no problem with it. Ian
Re: Type-punning
On Tue, 26 Jun 2007, Silvius Rus wrote:
> Herman Geza wrote:
> > aliasing when GCC (I think) incorrectly treats types different, but they're
> > the same. For example, I have:
> >
> > struct Point {
> > float x, y, z;
> > };
> >
> > struct Vector {
> > float x, y, z;
> >
> > Point &asPoint() {
> > return reinterpret_cast(*this);
> > }
> > };
> >
> > Point and Vector have the same layout, but GCC treats them different when it
> > does aliasing analysis. I have problems when I use Vector::asPoint.
> I also think this case should not be flagged. I have seen similar usage in
> network programming. Did it actually result in bad code or was it just the
> warning that bothered you?
Bad code. I thought this warning almost always means bad compiled code if
the casted object isn't casted back to its original type. However, I've
created a simple example, which does almost the same as the badly compiled
sourcecode. But this simple example compiled fine. I'm sure that the
badly compiled code is fine (I mean there is no programmer error, except
the type-punned warning), because:
- valgrind spotted only this (and the code doesn't behave as it should)
- if I change asPoint to toPoint (which returns a new Point object, not
a reinterpret_cast'd reference to *this), valgrind doesn't complain, and
the code runs fine.
I'll try to make a simple example on which GCC produces bad code.
Geza
Re: Type-punning
On Tue, Jun 26, 2007 at 11:42:27PM +0200, Herman Geza wrote:
> struct Point {
> float x, y, z;
> };
> struct Vector {
> float x, y, z;
>
> Point &asPoint() {
> return reinterpret_cast(*this);
> }
> };
> Point and Vector have the same layout, but GCC treats them different when
> it does aliasing analysis. I have problems when I use Vector::asPoint.
> I use asPoint very trivially, it is very easy to detect (for a human)
> that references point to the same address. Like
As a "human", I don't see how they are the same. Other than having three
fields with the same type, and same name, what makes them the same?
What happens when Point or Vector have a fourth field added? What if somebody
decides to re-order the fields to "float z, x, y;"? Would you expect the
optimization to be silently disabled? Or would you expect it to guess based
on the variables names?
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
. . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/|_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Re: Type-punning
On Tue, 26 Jun 2007 [EMAIL PROTECTED] wrote:
> On Tue, Jun 26, 2007 at 11:42:27PM +0200, Herman Geza wrote:
> > struct Point {
> > float x, y, z;
> > };
> > struct Vector {
> > float x, y, z;
> >
> > Point &asPoint() {
> > return reinterpret_cast(*this);
> > }
> > };
>
> > Point and Vector have the same layout, but GCC treats them different when
> > it does aliasing analysis. I have problems when I use Vector::asPoint.
> > I use asPoint very trivially, it is very easy to detect (for a human)
> > that references point to the same address. Like
>
> As a "human", I don't see how they are the same. Other than having three
> fields with the same type, and same name, what makes them the same?
Having the same layout makes them "the same".
> What happens when Point or Vector have a fourth field added? What if somebody
> decides to re-order the fields to "float z, x, y;"? Would you expect the
> optimization to be silently disabled? Or would you expect it to guess based
> on the variables names?
Point and Vector "designed" to have the same layout and nobody is allowed
to change this. It worked until now :)
Now, it seems a bad design, as the standard says at 3.10.15
(incomplete summary by me): a stored value can be accessed only with an
lvalue of the dynamic type of the stored object. They justify this with
aliasing. So a Vector shouldn't be accessed via a Point. Undefined
behavior happens if someone access an object via a different type
(unless it's char or unsigned char, which are allowed); same layout
doesn't matter, as Andrew P. said. The compiler is allowed to
generate bad code in this case, I think.
Geza
Re: Type-punning
On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote: Having the same layout makes them "the same". Not in C or C++ and in most cases of fortran too (unless you add an attribute). -- Pinski
Re: Type-punning
On Tue, 26 Jun 2007, Andrew Pinski wrote: > On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote: > > Having the same layout makes them "the same". > Not in C or C++ and in most cases of fortran too (unless you add an > attribute). Yes, it's clear now, thanks. However, it brings a new question: the standard defines layout-compatible types. For example, if I'm correct, my Vector and Point are layout compatible. What can I do with layout compatible objects? I found the definiton of layout compatible types, but found no uses of them. Why is it "important" that Point and Vector are layout-compatible? (is this question offtopic here?). Geza
Re: [tuples/LTO] RFC: houghts on auto-generating GS_* data structures
Ian Lance Taylor wrote: > Diego Novillo <[EMAIL PROTECTED]> writes: > > >> But, first, I'd like to know what folks think about this. Would it be >> generally useful for us to have the IL data structures auto-generated >> this way? I can see the benefits in the reader/writer. But also, we >> are going to have to re-implement the reader/writer when we move GIMPLE >> out of the tree data structures. OTOH, we will probably change them, >> add new codes and having them autogenerated may have other advantages. >> > > If we can use mmap to read the IL--which I personally think is going > to be a requirement for speed during the LTO phase--then this issue > does not necessarily arise. Rather than see work on this, I > personally would prefer to see work toward developing an IL which can > be read using mmap (possibly with pointer swizzling during the write > phase, which is less time critical). > > If it turns out that auto-generation is still useful during the write > phase, I have no problem with it. > > Ian > Ian, I do not necessarily believe that you are wrong, but you are not "obviously right" either. I understand the experience base that you come from: that of object code and linkers and in that world, doing this is an unquestionable "yes". But there are some features of that world that are not going to carry over here: In the linker world, you read (map) in a block, apply some relocations *in place* and write the block out [I get to ignore all of the work you do to figure out the relocations because it is irrelevant to this discussion.] In the lto world we will be reading in a function and then hacking on it. Many (most) of those hacks are not in place changes, but adding, deleting and rearranging instructions into the stream. Doing in place mapping puts severe restrictions on the kinds of storage managers that are going to be available to the rest of the compiler. They are going to have to be aware of the instructions (and other structures) that have been mapped in vs the instructions that are newly created and thus can be recovered. This is not impossible, it is merely hard. And the extent that it ends up slowing down both the development process and the resulting compiler is the basis for me saying that your idea is "not obviously correct". There is a strong argument for making developing the tools to generate the middle end data structures, even if we do not use them for lto: 1) It will force us into a discipline where we cannot do the braindead overloading that make the trees so difficult to manipulate. This is only doable if we start now before the rot sets in. 2) It will allow us to do lto serialization if we decide to. 3) If we decide we want tools to be able to write out, edit, modify and re-inject intermediate code into the compiler, the in and out part are easily derived from such a high level description. Kenny
[ARM] Cirrus EP93xx Maverick Crunch Support - "bge" pattern
G'day all,
As I wrote previously on gcc-patches (
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00244.html ), I'm working
on code to get the MaverickCrunch Floating-Point Co-processor supported
on ARM. I mentioned previously that you can't use the same opcodes for
testing GE on the MaverickCrunch, as you use on ARM. See the below
table for NZCV values from MaverickCrunch.
MaverickCrunch - (cfcmp*):
N Z C V
A == B 0 1 0 0
A < B 1 0 0 0
A > B 1 0 0 1
unord 0 0 0 0
ARM/FPA/VFP - (cmp*):
N Z C V
A == B 0 1 1 0
A < B 1 0 0 0
A > B 0 0 1 0
unord 0 0 1 1
I've added a new "maverick_comparison_operator" similar to
"arm_comparison_operator" to predicates.md, and added the right bits to
arm.md, as shown below:
;; Special predication pattern for Maverick Crunch floating-point
(define_cond_exec
[(match_operator 0 "maverick_comparison_operator"
[(match_operand:CCFP 1 "cc_register" "")
(const_int 0)])]
"TARGET_ARM && TARGET_HARD_FLOAT && TARGET_MAVERICK"
""
)
All the other predicates are fine, since they are only used in floating
point comparisons. But "ge" is also used for integer comparisons. Now,
my problem is with the following code:
; Special pattern to match GE for MAVERICK.
(define_insn "*arm_bge"
[(set (pc)
(if_then_else (ge (match_operand 1 "cc_register" "") (const_int 0))
(label_ref (match_operand 0 "" ""))
(pc)))]
"TARGET_ARM && TARGET_HARD_FLOAT && TARGET_MAVERICK"
"*
gcc_assert (!arm_ccfsm_state);
if (get_attr_cirrus (prev_active_insn(insn)) == CIRRUS_COMPARE)
return \"beq\\t%l0\;bvs\\t%l0\"; else return \"bge\\t%l0\;nop\";
"
[(set_attr "conds" "jump_clob")
(set_attr "length" "8")]
)
As you can see, I need to replace all bge with a maverick crunch
equivalent. However, "bge" is still also used with integer comparisons,
e.g:
double a, b;
if (a>=b) {
produces:
cfcmpd r15, mvd1, mvd0
beq .L4
bvs .L4
b .L2
.L4:
I haven't got a good example for the integer ge, but unsidf makes use of
ge (NB, I disabled MaverickCrunch 64-bit support for clarity, and
bugfixing):
unsigned int e = 9;
double e_d = e;
produces:
mov r3, #9
str r3, [fp, #-32]
ldr r0, [fp, #-32]
bl __aeabi_i2d
str r0, [fp, #-44]
str r1, [fp, #-40]
ldr r3, [fp, #-32]
cmp r3, #0
bge .L2
nop
mov r0, r0 @ nop
mov r0, r0 @ nop
cfldrd mvd0, .L4
mov r0, r0 @ nop
cfldrd mvd1, [fp, #-44]
mov r0, r0 @ nop
cfaddd mvd1, mvd1, mvd0
cfstrd mvd1, [fp, #-44]
.L2:
This seems to work fine for C code, but when I generate C++ code, I get
errors. Can anyone suggest a better way of writing the above code? I'd
rather the jump_clob didn't actually happen unless it was definitely a
cirrus compare, and not an ARM compare, but I can't seem to write the
code correctly.
Also, is "(get_attr_cirrus (prev_active_insn(insn)) == CIRRUS_COMPARE)"
the best way to find out if the last compare instruction was a cirrus
compare, or an ARM compare? Should I add a new routine to find the last
compare insn, e.g. prev_compare_insn??? I know that a branch doesn't
have to be directly after a comparison.
This and invalid coprocessor offset issue are the only two outstanding
bugs for MaverickCrunch support on the Cirrus EP93xx.
Re: [tuples/LTO] RFC: houghts on auto-generating GS_* data structures
Kenneth Zadeck <[EMAIL PROTECTED]> writes: > In the lto world we will be reading in a function and then hacking on > it. Many (most) of those hacks are not in place changes, but adding, > deleting and rearranging instructions into the stream. > > Doing in place mapping puts severe restrictions on the kinds of storage > managers that are going to be available to the rest of the compiler. > They are going to have to be aware of the instructions (and other > structures) that have been mapped in vs the instructions that are newly > created and thus can be recovered. I'm not sure I completely agree, or perhaps I don't completely understand. You can rearrange something that you mmap in, assuming you copy it in. Or just think the read system call, it doesn't really matter. I just think that if we have to take some action on every instruction we read in--i.e., parse it from bytecode into the internal representation--the I/O itself will be significant for LTO on a large program. Yes, memory management is more complex, but not that much more complex. Note that our GC system already understands what type of page an object is allocated in. > There is a strong argument for making developing the tools to generate > the middle end data structures, even if we do not use them for lto: > 1) It will force us into a discipline where we cannot do the braindead > overloading that make the trees so difficult to manipulate. This is > only doable if we start now before the rot sets in. > 2) It will allow us to do lto serialization if we decide to. > 3) If we decide we want tools to be able to write out, edit, modify and > re-inject intermediate code into the compiler, the in and out part are > easily derived from such a high level description. It's fine with me if you or somebody wants to tackle it. I agree that it brings benefits. I'm just not sure it's the most productive thing to work on. Ian
Re: Help on testsuite failures, only with optimization & bootstrap
On 6/26/07, Steve Ellcey <[EMAIL PROTECTED]> wrote:
After the dataflow merge (and after doing a couple of other patches that
were needed just to boostrap GCC on IA64 HP-UX), I am still getting some
failures in the GCC testsuite and am hoping for some advise / help on
figuring out what is going on.
A bunch of tests like the following one:
void __attribute__ ((__noinline__)) foo (int xf) {}
int main() { foo (1); return 0; }
Are failing because the generate the following warning:
$ obj_gcc/gcc/cc1 -quiet -O2 x.c
x.c:2: warning: inline function 'foo' given attribute noinline
Now, the problem here is, of course, that foo was no declared to be
inline and the warning should not be happening. If I recompile the GCC
file c-decl.c with -O2 -fno-tree-dominator-opts (instead of just -O2)
then the resulting GCC will not generate the warning message. But so
far I haven't been able to look at the tree dump files and see where
things are going wrong. It doesn't help that the dominator pass gets
run 3 times and I am not sure which one is causing the problem.
Unfortunately, I am only seeing this on IA64 HP-UX. It does not happen
on IA64 Linux.
Does anyone have any advice / ideas / recommendations on how to debug
this problem?
Steve Ellcey
[EMAIL PROTECTED]
If you want to find out exactl which invocation of dominator pass
is causing the problem,
I recommend adding a new dbg_cnt, something like (untested):
diff -r d856dc0baad4 gcc/dbgcnt.def
--- a/gcc/dbgcnt.defWed Jun 27 01:21:13 2007 +
+++ b/gcc/dbgcnt.defTue Jun 26 21:17:55 2007 -0700
@@ -84,3 +84,5 @@ DEBUG_COUNTER (tail_call)
DEBUG_COUNTER (tail_call)
DEBUG_COUNTER (global_alloc_at_func)
DEBUG_COUNTER (global_alloc_at_reg)
+DEBUG_COUNTER (uncprop_at_func)
+DEBUG_COUNTER (dominator_at_func)
diff -r d856dc0baad4 gcc/tree-ssa-dom.c
--- a/gcc/tree-ssa-dom.cWed Jun 27 01:21:13 2007 +
+++ b/gcc/tree-ssa-dom.cTue Jun 26 21:18:26 2007 -0700
@@ -44,6 +44,7 @@ Boston, MA 02110-1301, USA. */
#include "tree-ssa-propagate.h"
#include "langhooks.h"
#include "params.h"
+#include "dbgcnt.h"
/* This file implements optimizations on the dominator tree. */
@@ -365,7 +366,7 @@ static bool
static bool
gate_dominator (void)
{
- return flag_tree_dom != 0;
+ return flag_tree_dom != 0 && dbg_cnt (dominator_at_func);
}
struct tree_opt_pass pass_dominator =
diff -r d856dc0baad4 gcc/tree-ssa-uncprop.c
--- a/gcc/tree-ssa-uncprop.cWed Jun 27 01:21:13 2007 +
+++ b/gcc/tree-ssa-uncprop.cTue Jun 26 21:18:35 2007 -0700
@@ -40,6 +40,7 @@ Boston, MA 02110-1301, USA. */
#include "tree-pass.h"
#include "tree-ssa-propagate.h"
#include "langhooks.h"
+#include "dbgcnt.h"
/* The basic structure describing an equivalency created by traversing
an edge. Traversing the edge effectively means that we can assume
@@ -604,7 +605,7 @@ static bool
static bool
gate_uncprop (void)
{
- return flag_tree_dom != 0;
+ return flag_tree_dom != 0 && dbg_cnt (uncprop_at_func);
}
struct tree_opt_pass pass_uncprop =
This will at least allow you to fairly quickly find which invocation of the pass
is causing the problem, by doing a binary search on "n"
by adding the following extra flag to the compilation line:
-fdbg-cnt=uncprop_at_func:n
or
-fdbg-cnt=dominator_at_func:n
Of course, once you narrowed it down to that level,
you'll most likely still need to narrow it down further
but you'll have a better chance (you may want to add
another more fine grained dbgcnt for that).
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Re: [ARM] Cirrus EP93xx Maverick Crunch Support - "bge" pattern
if (get_attr_cirrus (prev_active_insn(insn)) == CIRRUS_COMPARE) return \"beq\\t%l0\;bvs\\t%l0\"; else return \"bge\\t%l0\;nop\"; " [(set_attr "conds" "jump_clob") (set_attr "length" "8")] ) As you can see, I need to replace all bge with a maverick crunch equivalent. However, "bge" is still also used with integer comparisons, e.g: I think you should generate the compare using a different mode for the CC register (like cc:CCMAV) and then use two patterns: ; Special pattern to match GE for MAVERICK. Most restrictive ; pattern goes first. (define_insn "*arm_cirrus_bge" [(set (pc) (if_then_else (ge (match_operand:CCMAV 1 "cc_register" "") (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] "TARGET_ARM && TARGET_HARD_FLOAT && TARGET_MAVERICK" "beq\\t%l0\;bvs\\t%l0\" [(set_attr "conds" "jump_clob") (set_attr "length" "8")] ) ; Special pattern to match GE for ARM. (define_insn "*arm_bge" [(set (pc) (if_then_else (ge (match_operand 1 "cc_register" "") (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] "TARGET_ARM && TARGET_HARD_FLOAT" "bge\\t%l0\" [(set_attr "conds" "jump_clob") (set_attr "length" "4")] )
