So we can do Intel, ATI and NVIDIA GPU backends. NVIDIA already has
an implementation of OpenCL working.
http://www.nvidia.com/object/cuda_opencl.html. Would there be any
sharing involved with them??
If you mean between backends, 1) do not underestimate the time needed to
write a new GCC
I've finished the first round of testing on all targets and will be
sending patches soon.
Overall, I think the results are quite satisfying.
For the current bunch of files, I get the same code on the following
targets:
m32c crx mmix xstormy16 fr30 v850 m32r iq2000 picochip mcore spu ia64
On Sun, Mar 22, 2009 at 15:41, Richard Kenner
ken...@vlsi1.ultra.nyu.edu wrote:
I must admit that this interpretation is quite new to me.
It certainly wasn't when EGCS reunited with gcc.
I disagree. reuniting with GCC means reuniting with the FSF.
... but not raising a white flag.
Paolo
Then you had the wrong understanding. The FSF has ALWAYS had the right to
overrule technical decisions on ANY of their projects. The point is that
this is a right they very rarely exercise.
Of course, just I (and others) don't see why they should do it in this
case. Delaying a *branch* is
Btw, I cannot find anything related to this discussion (about whether
and what power the FSF has to force their maintainers to do anything)
in the official FSF documentation (http://www.gnu.org/prep/maintain/).
Well, as the copyright owner and the appointer of maintainers it is
pretty obvious
Note that merging the branch will be painful (as in, please dissect
the branch into the individual patches again to make bisecting the
trunk SVN possible). Also the SC vetoed these kind of 'integration'
branches in the past (to not encourage starting an effective stage1
on a branch).
I
I don't understand this. Why does the SC have little power in this
matter? Surely you could decide to ship GCC 4.4 with the old license,
as the official GCC maintainer? But you *choose* not to use this
power (perhaps for good reasons, but I'm unconvinced).
The GCC maintainers work on
The most visible ongoing effort is the conversion from target macros
to target hooks (which is incomplete). The goal was to allow hot
swapping of backends. This is still the most obvious, most complete,
and least unappealing (from a technical POV) approach IMHO. But Kaveh
showed at one
I now went through all backends except sh and made the required changes.
So far all I tested is that gcc compiles with one target per port. :-)
Plus, i386-linux bootstraps and regtests okay.
Right now I aim at 100% identical assembly, maybe I'll have to relax
that. Besides obvious register
Martin Guy wrote:
On 3/14/09, Paolo Bonzini bonz...@gnu.org wrote:
Hans-Peter Nilsson wrote:
The answer to the question is no, but I'd guess the more
useful answer is yes, for different definitions of truncate.
Ok, after my patches you will be able to teach GCC about this definition
NightStrike wrote:
On Fri, Mar 13, 2009 at 1:58 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
Given the SC request we need to stay in Stage 4 rather than trying to work
around it.
What if GCC went back to stage 3 until the issue is resolved, thus
opening the door for a number of
villa gogh wrote:
hi
now i'm trying to construct def-use chain after the PASS_LEAF_REGS.
for the ssa form structure has been destoried during the former
passes.
I have found that gcc provides a way to build the def-use chain in the
PASS_REGRENAME, but it only contains the defs and uses all
Hans-Peter Nilsson wrote:
Date: Fri, 13 Mar 2009 12:34:49 +0100
From: Paolo Bonzini bonz...@gnu.org
I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
(which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
do not define it at all) it is right that shift
These are all the !SHIFT_COUNT_TRUNCATED targets.
For 4.5 I would like to improve our RTL canonicalization so that no
out-of-range shifts are ever in the RTL representation.
This in turn means that the description given by SHIFT_COUNT_TRUNCATED
must be exact. Right now !SHIFT_COUNT_TRUNCATED
Ian Lance Taylor wrote:
Paolo Bonzini bonz...@gnu.org writes:
This in turn means that the description given by SHIFT_COUNT_TRUNCATED
must be exact. Right now !SHIFT_COUNT_TRUNCATED means I don't know,
I want it to mean it is never truncated.
You need to do more work to make that happen
The Blackfin does not truncate shift counts. The documentation
specifies that e.g. for Dx = Dy instructions, shift counts greater
than 31 produce a result of zero. Other shift instructions use a sign
extended part of the shift count to shift either left or right. I
don't know is probably
/* Immediate shift counts are truncated by the output routines (or was it
the assembler?). Shift counts in a register are truncated by SH. Note
that the native compiler puts too large ( 32) immediate shift counts
into a register and shifts by the register, letting the SH decide what
Hm. In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts. Thus, Paolo, I think
what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED. No?
Unfortunately it is not so simple. fold-const.c is actually wrong, as
Hm. In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts. Thus, Paolo, I think
what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED. No?
Unfortunately it is not so simple. fold-const.c is actually wrong, as
Note, one thing I encountered when doing the SSE5 work at AMD, is
SHIFT_COUNT_TRUNCATED really needs a mode argument (and ideally should be
moved
into the gcc_target structure).
In fact I'm reusing the TARGET_SHIFT_TRUNCATION_MASK element that is
already there and accepts a mode.
Paolo
1) As multiple people said, it *was* a regression bug fix. It actually
fixed two regressions. (That it fixed the second was discovered only
after I committed it). I'm sorry that it caused problems for you (even
though it's actually lucky for GCC), but I can't help saying that it
might have been
In addition, all but one of the fixes that H.J. made (and for which I
have to thank him) were unrecognizable insns due to a misunderstanding
of how peephole2 worked
I stand corrected; *all* of the fixes. The patch hadn't had a
correctness problem until your message, only ice-on-valids. This
Toon Moene wrote:
H.J. Lu wrote:
If you can provide a testcase, I can take a look. If it isn't easy to
find
a testcase, please disable the second pattern:
(define_peephole2
[(set (match_operand 0 register_operand )
(match_operand 1 register_operand ))
(set (match_dup 0)
Attached you'll find the (preprocessed) source of the routine that
printed the Infinity's (of course, I cannot be completely certain that
it actually resulted in the wrong code, but at least it might be studied
to see if it helps to find the culprit).
No, this function is sane (the peephole
Toon Moene wrote:
Paolo Bonzini wrote:
Attached you'll find the (preprocessed) source of the routine that
printed the Infinity's (of course, I cannot be completely certain that
it actually resulted in the wrong code, but at least it might be studied
to see if it helps to find the culprit
Will REGNO (operands[0]) == REGNO (operands[1]) work here?
Yes. I wanted to be conservative in case one day subregs or who knows
what are allowed. I'll defer to maintainers or other people (Steven?),
either way is fine by me.
Paolo
Hi, I'll be posting soon a series of patches labeled [cond-optab].
The aim of the series is to have all ports use cbranch+cstore+cmov
optabs instead of cmp/bcc/scc/movcc. As a starter, the first patches
I'll post will be cleaning up and centralizing the generation of cmp,
scc and bcc opcodes.
I want the version of foo because the store with an address as
destination is costly on my architecture, which is why I defined
TARGET_ADDRESS_COST and added a cost when I get this scenario.
However, in the compilation of this code, it seems that, when the
function is inlined, the
Paolo Bonzini wrote:
I also wondered about this. I think the original idea is that splits
can call into dojump.c.
A more likely possibility is -fnon-call-exceptions.
Of course this is the main cause. But splitting one jump to multiple
jumps is supported and actually even documented
Timothy Madden wrote:
Hello
Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as
the in the online manual page ?
Yes. It might (*might*) be better in GCC 4.4 thanks to the new register
allocator, but it's unlikely that the manual page will be changed before
the release.
Well, the problem is that I don't know where to find the unofficial
documentation, so it is hard to figure out the questions to be asked.
Well, the unofficial documentation is the source code. :-
Paolo
Sylvain Pion wrote:
Andrew Thomas Pinski wrote:
The fact is that Roger's patch introduced a regression (this word
should be clear enough here), in that some users now have their old
code broken, and they are forced to add the -frounding-math option
(after having lost some time finding about
I think 2) is taken care of by -fassociative-math, or it should at least.
I don't think it is (I haven't checked), and I don't see why it should.
This transformation has nothing to do with associativity : unless I'm
mistaken, it is always valid when rounding is to the nearest or towards
1. Dataflow framework to propagate bitwise register properties.
(Integrated with the current dataflow framework.)
2. Forward bitwise dataflow analysis: constant bit propagation.
3. Backward bitwise dataflow analysis: dead bit propagation.
4. Target applications: improve dce and see.
So while trapping variants can certainly be introduced it looks like
this task may be more difficult.
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the front-end as
s = x +nv y
(((s ^ x) (s ^ y)) 0) ? trap () : s
d = x -nv y
(((d ^
Richard Guenther wrote:
On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini bonz...@gnu.org wrote:
So while trapping variants can certainly be introduced it looks like
this task may be more difficult.
I don't think you need to introduce trapping tree codes. You can
introduce them directly
Joseph S. Myers wrote:
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the front-end as
Multiple front ends want the same thing. This is why it would be better
to introduce the codes in GENERIC
Joseph S. Myers wrote:
On Fri, 6 Mar 2009, Geert Bosch wrote:
this task may be more difficult. So lowering them early during
gimplification looks like a more reasonable plan IMHO.
Right, that was my intention. Still, I'll need to add code to
handle the new tree codes in fold(), right?
If this does not work, on ARM you can also hope for something like this:
ADDR0, R1, R2
XORS R0, R2, R3
XORSMI R1, R2, R3
SWIMI #trap
On ARM you can just check for overflow directly...
ADDSR0, R1, R2
SWIVS #trap
Of course, I was thinking
Uwe Kleine-König wrote:
Hello,
currently[1] __builtin_return_address for ARM only works with level == 0.
For ftrace in the linux kernel it would be great to implement that for
level 0 (provided that framepointers or unwind information are
available of course). On the linux-arm-kernel ML
Currently, we have to use intrinsics to support such shift. Isn't syntax of
vector
shift intuitive enough to be supported natively? Someone may argue it breaks
the
C language. But vector is a GCC extension anyway. Support for vector
add/sub/etc
already break C syntax. Any thought? Sorry
It shouldn't be too hard to add the support. I suspect the person who did
the
initial support may have been on a machine without vector shifts.
Nope, because it was originally done by Aldy who did the VMX support
which had vector shifts.
OTOH the support for vector lowering was weaker
Jack Howarth wrote:
The same issue in the libiberty testsuite run can be seen with
the Apple regress server log at
http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip.
If you search for test-demangle, you will find...
I'm sure there is a bugzilla entry for that.
Paolo
-Wstrict-aliasing
This option is only active when -fstrict-aliasing is active. It
warns about code which might
break the strict aliasing rules that the compiler is using for
optimization. The warning does
not catch all cases, but does attempt to catch the more common
pitfalls. It is
Jeff Law wrote:
We'd want to encode [early insn alternative selection]
information in the conflict graph so that IRA would
allocate registers so as to fit the constraints of the early insn
alternative selection. Right? In the case where the graph is
uncolorable, do we allow IRA to override
However, I don't agree that P2 regressions aren't a factor. If we have
a ton of crashing on wrong-code, etc., regressions that adds up to a
release that won't work well for people.
In which case the important ones should be P1 ...
No, that misses the point. A mass of bugs, each itself not
Assuming you have a copyright assignment, just send a patch to
gcc-patches with the explanation. This is code which will never be used
for any popular target.
The patch is probably small enough that it does not require assignment,
given the description in his original message.
Paolo
Bingfeng Mei wrote:
Hello,
Could anyone explain to me what is difference between
vec_shl_vector_mode and ashlvector_mode3 patterns? It seems to me
that both shift a vector operand 1 with scalar operand 2. I tried to
understand some targets' implemenation, e.g., ia64 as follows, and
cannot
- The more conservative one is to use more aggressively the release
milestone field. Hard-to-fix bugs would be left as P2, but bumped to
the next major release at the beginning of stage 3.
Advantages: no need for churn in the bug database---very easy to implement
Disadvantages: the
Jean Christophe Beyler wrote:
Ok, thanks for all this information and if you can dig that up it
would be nice too. I'll start looking at that patch and PR33699 to
see if I can adapt them to my needs.
Here it is.
Paolo
/* Copy propagation on RTL for GNU compiler.
Copyright (C) 2006 Free
Steven Bosscher wrote:
On Fri, Feb 6, 2009 at 7:32 PM, Adam Nemet ane...@caviumnetworks.com wrote:
I think you really need the Joern's optmize_related_values patch. Also see
PR33699.
I wouldn't recommend that patch, but yes: Something that performs that
optimization ;-)
Yes, something
The current system for managing bugzilla priorities has a major problem,
in that it does not identify bugs that reasonably cannot be fixed before
the release.
The current set of priorities is in practice like this:
- P1: most wrong code bugs, and other absolutely blocking problems
- P2: problems
I am just starting to think about adding OpenCL support into future versions
of
GCC, as it looks like a useful way of programming highly parallel type
systems,
particularly with hetrogeneous processors. At this point, I am wondering what
kind of interest people have in working together
Although the OpenCL infrastructure doesn't confine itself to it, this
compute-on-the-graphic-processor type of parallellism mostly concerns
itself with let's do the FFT (or DGEMM) really fast on this processor
and then return to the user.
Not really, it's not about FFT/DGEMM only -- the
Joern Rennecke wrote:
Quoting Ian Lance Taylor i...@google.com:
I'm not sure what your point is here. newlib is not under the GPL in
any case. It is not affected by the gcc runtime library license.
The old runtime library exception allowed you to distribute binaries that
both include
Bruce Korb wrote:
Hi,
I was trying to figure out how come a memory allocation was short.
I think I've stumbled onto the issue. evt_t is a 48 byte structure
and tpd_uptr is a uintptr_t. sz initializes to 52 (decimal).
The value would be correct if I were not trying to multiply the
size of
He'll get much better code by putting the program into a -fPIC .so,
loading it from a small stub and then unmap the stub.
large model generates really very bad code because all jumps
will be indirect.
Is it also true with -fpie?
Paolo
Andi Kleen wrote:
On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
He'll get much better code by putting the program into a -fPIC .so,
loading it from a small stub and then unmap the stub.
large model generates really very bad code because all jumps
will be indirect.
Is it also
James Dennett wrote:
On Mon, Jan 26, 2009 at 11:52 PM, zol...@bendor.com.au wrote:
I was debugging a function and by inserting the debug statement crashed
the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
from sources) with -O2 under some circumstances assumes that if
However, -fno-delete-null-pointer-checks will do.
Not for PTA though ;)
Care to expand?
Paolo
Not for PTA though ;)
Care to expand?
PTA tracks points-to-NULL as pointing to nothing.
This probably should be conditional on -fdelete-null-pointer-checks.
Otherwise *NULL and *anything won't alias.
Yes, you're right. I'll see if I can construct a testcase and a patch.
BTW, I was
Richard Guenther wrote:
On Tue, Jan 27, 2009 at 11:35 AM, Paolo Bonzini bonz...@gnu.org wrote:
Not for PTA though ;)
Care to expand?
PTA tracks points-to-NULL as pointing to nothing.
This probably should be conditional on -fdelete-null-pointer-checks.
Otherwise *NULL and *anything won't
int *
x(void)
{
register int *a asm(unknown_register); /* { dg-error invalid register
} */
int *v[1] = {a};
return v[1];
}
I think simply scalarizing for the above testcase is ok - the behavior
is
movl.s %edi, %edi
pushl %ebp
movl.s %esp, %ebp
Have you thought about making .s an assembler command-line flag, so that
this flag could be passed automatically by the compiler under mingw?
Paolo
For my purposes it is not really suitable, because we have to make sure that
the push %ebp and mov %esp, %ebp are there, no matter what the compiler
arguments are(-fomit-frame-pointer). So just adding the mov %edi, %edi isn't
enough, and while I'm at it I can add the .s to the insns anyway.
Which version of gcc did you use? gcc 4.1 (maybe and 4.2) will report
error. But gcc 4.3 compiles OK. I tested using x86_64 native gcc from
Debian unstable. __emutls_get_address is defined in libgcc even the
target has real TLS.
Uff... not my day. I used 4.2 (emutls was posted in 4.2 time
I have here an (attached) testcase which unexpectedly turns off
warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:
test.c: In function 'pam_sm_authenticate':
test.c:6: warning: implicit declaration of function 'undef'
This works on the trunk but fails on the 4.3 branch.
Rafael Espindola wrote:
Because the right one should have been
$ git config --add remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
That is what git clone adds, but with that git branch -r will not
list the remote branches.
Uhm, it does here (I don't have a GCC repo, it's another
Rafael Espindola wrote:
git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
This will put the remote branch heads in refs/remotes, you might want to
put them in refs/remotes/origin instead.
$ git config --add remote.origin.fetch
'+refs/remotes/*:refs/remotes/origin/*'
Andreas Schwab wrote:
Why is the libjava directory configured with raw_cxx?
Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
The problem with this is that it keeps the libtool test for dynamic
linker characteristics from working properly, due to the undefined
Andreas Schwab wrote:
Paolo Bonzini bonz...@gnu.org writes:
If it bothers you (does it cause a PR?),
It causes a program to fail to run during build.
./gcj-dbtool -n classmap.db || touch classmap.db
/usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool:
error
If it bothers you (does it cause a PR?),
It causes a program to fail to run during build.
./gcj-dbtool -n classmap.db || touch classmap.db
/usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool:
error while loading shared libraries: libgcj.so.10: cannot open shared
The main difference that springs to mind: SIN is built-in, MATMUL is a
library
function. In gcc/builtin.defs, one finds
Not just that: SIN is a pure (or const, depending on -frounding-math)
function, which can be subject to CSE and DCE. I don't see anything
suggesting that for MATMUL in
To get around this you'd have to either
link a separate copy of the plugin for each executable, or access the
symbols in the executable indirectly through GetProcAddress and function
pointers.
Hacking the compiler (or postlinker!) to emit a special constructor that
does the necessary
Thomas Schwinge wrote:
Hello!
We, the GNU Hurd people, would like to get GCC in a compilable/usable
shape for us again, without needing to do the patching that was needed
since the 4.2 release. I have already some weeks ago sent the needed
patches to the gcc-patches mailing list, where
though that is probably inadequate.
Especially because Makefile.in is automatically generated. :-)
It's not the default goal that matters, but if bootstrap4 is a goal at all.
Or if compare3 is a goal.
I have a (correct) patch which I'll apply in a day or two.
Thanks,
Paolo
The following ports haven't been converted yet:
arc m32c m68hc11 mmix pdp11 score vax
DJ has reported problems on the list for m32c.
Regarding ARC and MMIX we might expect some action from Joern and H-P
respectively, but nobody is probably going to do the work for the others
Paolo
Farlie A wrote:
Hi,
Would you be willing to consider supporting the PE object formats on the
ARM based port of ReactOS?
If you are willing to contribute code for this, that's possible indeed.
Otherwise, no one will probably do the work.
Paolo
This means that you couldn't use *GCC* if you
did something the FSF found objectionable, closing an easy
work-around.
This doesn't work, because it breaks out of the basic framework of
copyright law. Nobody signs anything or accepts any terms in order to
use gcc. The FSF wants to stop
Off-topic, but I feel this is important, since Apple contributed to gcc,
and it is licensed under GPLv3 now.
The license of GCC does not matter, unless the iPhone includes a copy of
GCC's binaries for a recent-enough version. In which case, of course,
Apple would be violating the GPLv3 and you
Peter O'Gorman wrote:
Yuhong Bao wrote:
and Apple uses GCC (which is now under GPLv3) and Mac OS X on it.
Unfortunately, the iPhone is incompatible with GPLv3, if you want more see
the link I mentioned.
Apple does not use a GPLv3 version of GCC.
Ah, actually I think I now see the OP's
Well at least that explains their total inactivity in the last year. Is Dale
the one still allowed to read the gcc-patches mailing list?
No, that would be Stan just because he's not at Apple.
It must be said also that Mike Stump accepted to review/discuss
Darwin/ObjC patches that he was CCed
Steven Bosscher wrote:
On Wed, Sep 24, 2008 at 4:06 PM, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Apple's dislike of GPLv3 is a problem for gcc, yes.
Well, excuse me for being a-political, but I don't see this problem.
The relationship between GCC and Apple has never been really good
AFAIK,
Diego Novillo wrote:
On Fri, Sep 19, 2008 at 12:55, Jakub Jelinek [EMAIL PROTECTED] wrote:
On Fri, Sep 19, 2008 at 12:36:12PM -0400, Diego Novillo wrote:
When we instantiate char_type_node in tree.c:build_common_tree_nodes
we very explicitly create a char_type_node that is signed or unsigned
I think our mxp is more 'interesting'. [snip]
I think it's more like 'insane', :-) and a miracle that a retargetable
compiler can be ported to it.
Paolo
Thomas A.M. Bernard wrote:
Well I found another way to solve the problem by updating the dce for
not taking out my instructions.
I inserted setallocate as a native operator in the back-end which
comes from a GIMPLE node and map to the RTL pattern. Earlier in the
discussion, it's been
Thomas A.M. Bernard wrote:
I have tried unspec_volatile without success though. As
follow,
(define_insn setallocate
[(setallocate
(unspec_volatile:DI [ (match_operand:DI 0 general_operand
r)]
UNSPEC_ALLOCATE)
)]
allocate
Rainer Emrich wrote:
[EMAIL PROTECTED] schrieb:
Rainer Emrich [EMAIL PROTECTED] wrote:
So I wan't to pass LDFLAGS=-Wl, -rpath, /somedir to stage3 to link gcc,
cpp,
etc. with the rpath information.
I do this by editing LDFLAGS_FOR_TARGET in the top-level Makefile.in,
and also passing
Well, libtool-2.2.6 is finally released (twice even).
Actual approval depends on your answer to this question, but the patch is
technically okay. Can you commit it to the src repository too? There is
some regeneration to do there too.
I know that GCC is now in stage 3, and that we
Peter O'Gorman wrote:
On Mon, Sep 08, 2008 at 08:29:37PM +0200, Paolo Bonzini wrote:
Well, libtool-2.2.6 is finally released (twice even).
Actual approval depends on your answer to this question, but the patch is
technically okay. Can you commit it to the src repository too? There is
some
As H-P says, the predicates on move expanders are generally ignored.
emit_move_insn subroutines deliberately don't check them.
It's even worse; force_reg is effectively hardcoding movXX's operand 1
to be a general_operand. (But my point was that force_reg does use
LEGITIMATE_CONSTANT_P
Only with a LEGITIMATE_CONSTANT_P catching it...
Of course.
So, can we agree on some or all of:
1. This (PR37363/PR36182) and PR36090 (in both ports) and
whatever other port will be affected should be solved by a
stricter LEGITIMATE_CONSTANT_P check, and where
canonicalization
Hans-Peter Nilsson wrote:
Date: Fri, 5 Sep 2008 14:57:00 +0200
From: Hans-Peter Nilsson [EMAIL PROTECTED]
Maybe as part of a change from target macro to target hook, with
LEGITIMATE_CONSTANT_P as a default would fit, even at this
stage?
Sorry, I mean CONSTANT_P, not
Paolo Bonzini wrote:
Hans-Peter Nilsson wrote:
Date: Fri, 5 Sep 2008 14:57:00 +0200
From: Hans-Peter Nilsson [EMAIL PROTECTED]
Maybe as part of a change from target macro to target hook, with
LEGITIMATE_CONSTANT_P as a default would fit, even at this
stage?
Sorry, I mean CONSTANT_P
), but it's probably better to clean up instead. What
do you thing about the simplify-rtx.c part instead?
Paolo
2008-09-06 Paolo Bonzini [EMAIL PROTECTED]
* cse.c (fold_rtx): Let simplify_unary_operation handle CONSTs.
* explow.c (plus_constant): Don't exit early if c == 0
if plus_constant _knows_ that something can be wrapped in a CONST,
simplify_binary_operation should have given us the CONST to begin with.
Also, the only cases that plus_constant can handle are CONST,
SYMBOL_REF and LABEL_REF, all of which satisfy CONSTANT_P.
So the new form ought to be dead
In case of cris, the predicate goes into general_operand, which does
if (CONSTANT_P (op))
return ((GET_MODE (op) == VOIDmode || GET_MODE (op) == mode
|| mode == VOIDmode)
(! flag_pic || LEGITIMATE_PIC_OPERAND_P (op))
LEGITIMATE_CONSTANT_P (op));
I got negative feedback on that patch (no, not regression
results :) on IRC from David Edelsohn and understandably you
held off your testing because of this, as for one the patch
affects the rs6000 backend.
What kind of negative feedback?
For CRIS (as well as other targets IIUC) the cause
3) adding a check that the MINUS is a legitimate address, and only wrap
it in CONST if it is.
s/address/constant/; it's not clear that it's used as an address
at that point; it's just two expressions that gcc tries to
reduce.
Right.
But I get the point; I'm leaning towards something
David Edelsohn wrote:
On Wed, Sep 3, 2008 at 6:53 PM, Anton Blanchard [EMAIL PROTECTED] wrote:
The only thing lwsync wont order is a store followed by a load. Since
the lwsync will always be paired with a store (the stwcx), we will order
all accesses before it and provide a release barrier.
901 - 1000 of 1512 matches
Mail list logo
