Re: Stage1 ?
On Fri, 2005-05-06 at 07:06 +0200, Stephane Wirtel wrote: > Hi all, > > I would like to know how many stages are there ? > What's the first stage ? > http://gcc.gnu.org/develop.html -eric
Re: Stage1 ?
On Thursday, May 5, 2005, at 10:06 PM, Stephane Wirtel wrote: I would like to know how many stages are there ? What's the first stage ? Denial, wait, or was that the last one... :-) Click on Stage 1 on our web site, then read...
Re: GCC 4.1: Buildable on GHz machines only?
We could allow different amounts of aggregation other than 0% or 100%; that might help some builds. Per-directory could be useful to the guys using the static library, too. But what Per is talking about is how .o files are built. This change would probably not be very difficult fwiw; we already have done this in a place or two where we've needed BC ABI support. As long as libtool supports it, it should not be very difficult indeed. Paolo
Re: GCC 4.1: Buildable on GHz machines only?
We could allow different amounts of aggregation other than 0% or 100%; that might help some builds. Per-directory could be useful to the guys using the static library, too. But what Per is talking about is how .o files are built. This change would probably not be very difficult fwiw; we already have done this in a place or two where we've needed BC ABI support. As long as libtool supports it, it should not be very difficult indeed. Paolo
Re: __builtin_isless, __builtin_islessequal on mips targets
On Thu, 2005-05-05 at 15:58 +0400, Nadezhda IvanÐvna Vyukova wrote: > The __builtin_isless, __builtin_islessequal functions are provided as > implementations of standard C99 functions 'isless', 'isgreater'. Please, > explain why gcc for mips implements them via instructions > > c.lt.FMT and > c.le.FMT > > instead of > > c.olt.FMT and > c.ole.FMT. No reason in particular. The only difference is that the first will signal an exception on QNaN and the second won't, thereby simplifying the programming model. Do you have a good reason for doing it the other way? -eric
Re: check_ext_dependent_givs
Canqun Yang wrote: Hi, all, Is there anyone familiar with the check routine check_ext_dependent_givs defined loop.c, and give me an example explaining why it is needed. You should not look at loop.c to modify it, because it will hopefully disappear before 4.1. But basically, that function looks for code like this short i; long j; for (i = 30; i != 10; i++) j = (long) i; ... which you cannot transform into short i; long j; for (i = 30, j = 30; i != 10; i++, j++) ... The bulk of the check is in biv_fits_mode_p. Paolo
RFD: Is there a helper function like "print_rtx_to_stdout" ?
Hi,
I am facing a situation where a gcc_assert call that checks for some
properties of a rtx expression, say "op", triggers an ICE (see below). I'd
like to have a look the rtx that triggers this error. For this reason, I'd
like to know whether there exists a helper function for writing to stdout
which kind of rtx "op" actually is. I.e. some function like
"print_rtx_to_stdout" or "print_rtx_to_file" that could be used when
debugging the compiler.
Thank's in advance.
Björn
Sample code:
rtx
simplify_subreg (enum machine_mode outermode, rtx op,
enum machine_mode innermode, unsigned int byte)
{
/* Little bit of sanity checking. */
gcc_assert (GET_MODE (op) == innermode || GET_MODE (op) == VOIDmode);
...
Re: GCC 4.1: Buildable on GHz machines only?
Rutger Ovidius writes: > Thursday, May 5, 2005, 1:16:05 PM, you wrote: > > RH> On Thu, May 05, 2005 at 04:57:48PM -0300, Alexandre Oliva wrote: > >> The savings of creating static libraries would be small if we > >> refrained from building non-PIC object files. > > RH> But still largely useless. Who in their right mind is going to > RH> use an 83MB static library when a shared library is available. > > Everyone on win32 builds libgcj static, and probably wants to keep it > that way if they plan to distribute their apps. > > What would be the point of distributing a giant shared library with > every application compiled with gcj, especially when awt/swing only > hook into gtk? > > I don't think libgcj.dll will ever be standard on any distribution of > win32, yet the many advantages of compiling java code to fast, native > executables apply on this platform. I don't think that anyone is proposing to drop static libraries on Win32. Win32 systems have their own requirements that make static libs preferable in some cases. On GNU systems, however, static libs make no sense at all for the Java language. Andrew.
Re: RFD: Is there a helper function like "print_rtx_to_stdout" ?
On Friday, May 6, 2005, at 12:57 AM, Björn Haase wrote: I'd like to have a look the rtx that triggers this error. p x pr in gdb. See gcc/gdbinit.in for yet more functions.
How to get MIN_EXPR without using deprecated min operator
Consider the following short program:
#include
void Tst1(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; x
Re: __builtin_isless, __builtin_islessequal on mips targets
Nadezhda Ivanоvna Vyukova <[EMAIL PROTECTED]> writes: > The __builtin_isless, __builtin_islessequal functions are provided as > implementations of standard C99 functions 'isless', 'isgreater'. Please, > explain why gcc for mips implements them via instructions > > c.lt.FMT and > c.le.FMT > > instead of > > c.olt.FMT and > c.ole.FMT. Ouch, well spotted. This is definitely a bug. Could you file a report in bugzilla for it? Thanks. Richard
RE: Is there a helper function like "print_rtx_to_stdout" ?
Original Message >From: Björn Haase >Sent: 06 May 2005 08:57 > like to know whether there exists a helper function for writing to stdout > which kind of rtx "op" actually is. I.e. some function like > "print_rtx_to_stdout" or "print_rtx_to_file" that could be used when > debugging the compiler. See print-rtl.c cheers, DaveK -- Can't think of a witty .sigline today
Re: Is there a helper function like "print_rtx_to_stdout" ?
Best thanks for your fast reply! ... did not know that gdb has support for printing RTX. *VERY* useful feature (and much better than temporary including debugging printout commands in the compiler itself :-) ). Yours, Björn
RE: Is there a helper function like "print_rtx_to_stdout" ?
Original Message >From: [EMAIL PROTECTED] >Sent: 06 May 2005 12:06 > Best thanks for your fast reply! > Glad to help! :) > ... did not know that gdb has support for printing RTX. *VERY* useful > feature (and much better than temporary including debugging printout > commands in the compiler itself :-) ). > > Yours, > > Björn FYI, the gdb commands Mike referred you to in gcc/gdbinit.in work by causing gdb to call the functions I referred you to in print-rtl.c in the debugged (inferior) gcc at runtime. cheers, DaveK -- Can't think of a witty .sigline today
Re: How to get MIN_EXPR without using deprecated min operator
"Michael Cieslinski" <[EMAIL PROTECTED]> writes:
| Consider the following short program:
|
| #include
|
| void Tst1(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
| {
| for (int x=0; xhttp://gcc.gnu.org/bugzilla/
for missed optimization.
-- Gaby
Re: How to get MIN_EXPR without using deprecated min operator
Michael Cieslinski wrote:
Consider the following short program:
#include
void Tst1(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; x
MinP[x] = SrcP[x]
}
void Tst2(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; x
MinP[x] = std::min(SrcP[x], MinP[x]);
}
If I compile it with
gcc41 -O2 -ftree-vectorize -ftree-vectorizer-verbose=5
function Tst1 gets vectorized but Tst2 not.
The reason for this is
Out of interest, do you get vectorisation from:
MinP[x] = (SrcP[x]
Chris
Re: How to get MIN_EXPR without using deprecated min operator
On May 6, 2005, at 9:27 AM, chris jefferson wrote:
Michael Cieslinski wrote:
Consider the following short program:
#include
void Tst1(short* __restrict__ SrcP, short* __restrict__ MinP,
int Len)
{
for (int x=0; x
MinP[x] = SrcP[x]
}
void Tst2(short* __restrict__ SrcP, short* __restrict__ MinP,
int Len)
{
for (int x=0; x
MinP[x] = std::min(SrcP[x], MinP[x]);
}
If I compile it with
gcc41 -O2 -ftree-vectorize -ftree-vectorizer-verbose=5
function Tst1 gets vectorized but Tst2 not.
The reason for this is
conditional code.
My question is, how can I get a MIN_EXPR without using the deprecated
min
operator?
The problem with C++ is in fold as we now have to disable the
optimization
which converted "a >= b ? b : a" to MIN_EXPR.
Try the following instead:
MinP[x] = (SrcP[x]
which forces this to be an rvalue instead of the normal lvalue which
should
allow fold to convert this to MIN_EXPR
-- Pinski
Re: RFD: Is there a helper function like "print_rtx_to_stdout" ?
On May 6, 2005, at 3:57 AM, Björn Haase wrote: Hi, I am facing a situation where a gcc_assert call that checks for some properties of a rtx expression, say "op", triggers an ICE (see below). I'd like to have a look the rtx that triggers this error. For this reason, I'd like to know whether there exists a helper function for writing to stdout which kind of rtx "op" actually is. I.e. some function like "print_rtx_to_stdout" or "print_rtx_to_file" that could be used when debugging the compiler. Thank's in advance. debug_rtx -- Pinski
Re: GCC 4.1: Buildable on GHz machines only?
Friday, May 6, 2005, 1:33:32 AM, you wrote: AH> Rutger Ovidius writes: >> Thursday, May 5, 2005, 1:16:05 PM, you wrote: >> >> RH> On Thu, May 05, 2005 at 04:57:48PM -0300, Alexandre Oliva wrote: >> >> The savings of creating static libraries would be small if we >> >> refrained from building non-PIC object files. >> >> RH> But still largely useless. Who in their right mind is going to >> RH> use an 83MB static library when a shared library is available. >> >> Everyone on win32 builds libgcj static, and probably wants to keep it >> that way if they plan to distribute their apps. >> >> What would be the point of distributing a giant shared library with >> every application compiled with gcj, especially when awt/swing only >> hook into gtk? >> >> I don't think libgcj.dll will ever be standard on any distribution of >> win32, yet the many advantages of compiling java code to fast, native >> executables apply on this platform. AH> I don't think that anyone is proposing to drop static libraries on AH> Win32. Win32 systems have their own requirements that make static AH> libs preferable in some cases. On GNU systems, however, static libs AH> make no sense at all for the Java language. One of the first things I had hoped for from gcj was static linking (except for libc) on GNU systems. There is new era of shared library hell and it seems to only apply to libgcj. Having to manually pare down the libgcj .so and distribute it with apps seems necessary; expecting target users of a new gcj compiled app to have an absolutely up-to-date and compatible libgcj.so (probably compiled with small patches along the way to make this specific app work) is not reasonable. Plus, the release cycle of gcc will never match the development speed of libgcj. There are die hard followers of gcc that do have up to date systems, but the vast majority do not and never will. Java is a simple language, used as the intro learning language in most universities that I know of. Not having to plan memory management like c++ motivates very fast development. Compiling small utils with it and having them be portable, even on GNU systems, is an incredible selling point. This isn't really possible without static linking. Sometimes I see a great divide between the developers of gcj, and the actual users of it. It seems to only target the server setting, or the user who wishes to compile existing apps and only run them on their own system. This target could be much wider in scope with static linking.
Re: GCC 4.1: Buildable on GHz machines only?
Rutger Ovidius writes: > Friday, May 6, 2005, 1:33:32 AM, you wrote: > > AH> I don't think that anyone is proposing to drop static libraries on > AH> Win32. Win32 systems have their own requirements that make static > AH> libs preferable in some cases. On GNU systems, however, static libs > AH> make no sense at all for the Java language. > > One of the first things I had hoped for from gcj was static linking > (except for libc) on GNU systems. > > There is new era of shared library hell and it seems to only apply to > libgcj. Having to manually pare down the libgcj .so and distribute it > with apps seems necessary; expecting target users of a new gcj > compiled app to have an absolutely up-to-date and compatible libgcj.so > (probably compiled with small patches along the way to make this > specific app work) is not reasonable. Yes, which is why we're redesigning the ABI so that compiled apps won't depend on a specific release of the library. We're fixing the real problem rather than depending on nasty kludges like static linking. > Plus, the release cycle of gcc will never match the development > speed of libgcj. There are die hard followers of gcc that do have > up to date systems, but the vast majority do not and never will. That too. > Java is a simple language, used as the intro learning language in most > universities that I know of. Not having to plan memory management like > c++ motivates very fast development. Compiling small utils with it and > having them be portable, even on GNU systems, is an incredible selling > point. Is it really? There are users out there insane enough to be passing around precompiled binaries of small utils? > This isn't really possible without static linking. But Java isn't compatible with static linking. Java is, by its very nature, a dynamic language, where classes invoke and even generate other classes on the fly. There is no way when linking to determine what set of libraries is required. This is a simple fact, and no amount of declaring " this is what users want!" is going to change it. > Sometimes I see a great divide between the developers of gcj, and > the actual users of it. Spare us the ad homs, please. Andrew.
Re: GCC 4.1: Buildable on GHz machines only?
Hi Rutger, On Fri, 2005-05-06 at 07:24 -0700, Rutger Ovidius wrote: > AH> I don't think that anyone is proposing to drop static libraries on > AH> Win32. Win32 systems have their own requirements that make static > AH> libs preferable in some cases. On GNU systems, however, static libs > AH> make no sense at all for the Java language. > > One of the first things I had hoped for from gcj was static linking > (except for libc) on GNU systems. > > There is new era of shared library hell and it seems to only apply to > libgcj. I might be to young to have experienced this last era of share library hell. Do you have a pointer to what you are referring to and how it was solved back then on GNU systems? > Plus, the release cycle of gcc > will never match the development speed of libgcj. There are die hard > followers of gcc that do have up to date systems, but the vast > majority do not and never will. This is indeed a problem. But it has a happy cause, GNU Classpath and libgcj development is going really strong and fast. We are slowly working towards both working closer with the rest of GCC (sharing more infrastructure) and decoupling some of the development a bit more (the new bc-abi indirect-dispatch introduced in gcj 4). But it might take a couple of gcc releases till we have the right balance. > Sometimes I see a great divide between the developers of gcj, and the > actual users of it. It seems to only target the server setting, or the > user who wishes to compile existing apps and only run them on their > own system. This target could be much wider in scope with static > linking. Where/How do these actual users communicate about the problems they are experiencing and the disconnect between us developers and them? I would like to better understand the actual problems these users see that we developers might be missing. Thanks, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: GCC 4.1: Buildable on GHz machines only?
Paolo Bonzini wrote: >> But what Per is talking about is how .o files are built. This change would probably not be very difficult fwiw; we already have done this in a place or two where we've needed BC ABI support. As long as libtool supports it, it should not be very difficult indeed. It semi-supports it. I build Kawa one directory at a time, using libtool. (Albeit the CVS version of libtool.) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.1: Buildable on GHz machines only?
Friday, May 6, 2005, 8:06:49 AM, you wrote: AH> Rutger Ovidius writes: >> Friday, May 6, 2005, 1:33:32 AM, you wrote: >> >> AH> I don't think that anyone is proposing to drop static libraries on >> AH> Win32. Win32 systems have their own requirements that make static >> AH> libs preferable in some cases. On GNU systems, however, static libs >> AH> make no sense at all for the Java language. >> >> One of the first things I had hoped for from gcj was static linking >> (except for libc) on GNU systems. >> >> There is new era of shared library hell and it seems to only apply to >> libgcj. Having to manually pare down the libgcj .so and distribute it >> with apps seems necessary; expecting target users of a new gcj >> compiled app to have an absolutely up-to-date and compatible libgcj.so >> (probably compiled with small patches along the way to make this >> specific app work) is not reasonable. AH> Yes, which is why we're redesigning the ABI so that compiled apps AH> won't depend on a specific release of the library. We're fixing the AH> real problem rather than depending on nasty kludges like static AH> linking. It would be a feature; a kludge seems to be your opinion, and no one would depend upon it. I don't think having the option to link static would affect the natural java way(?) of linking dynamically. >> Java is a simple language, used as the intro learning language in most >> universities that I know of. Not having to plan memory management like >> c++ motivates very fast development. Compiling small utils with it and >> having them be portable, even on GNU systems, is an incredible selling >> point. AH> Is it really? There are users out there insane enough to be passing AH> around precompiled binaries of small utils? I don't need to pass it around to anyone else to experiene the limitation. The utilities can be moved on to systems on which I do not have access to install the latest gcc globally. I must also include a large libgcj each time. >> This isn't really possible without static linking. AH> But Java isn't compatible with static linking. Java is, by its very AH> nature, a dynamic language, where classes invoke and even generate AH> other classes on the fly. There is no way when linking to determine AH> what set of libraries is required. This is a simple fact, and no AH> amount of declaring " this is what users want!" is going to change AH> it. I didn't know that java had a nature. It has features. Some features will work when it is implemented in a certain way and some won't. Compiling natively with GCJ adds the opportunity to add features. Static linking would be a feature. I don't think "natural java" supports CNI, but this is a nice feature that compiling with gcj adds. >> Sometimes I see a great divide between the developers of gcj, and >> the actual users of it. AH> Spare us the ad homs, please. I think I can freely express a personal viewpoint just like you have above. Thank you.
Re: GCC 4.1: Buildable on GHz machines only?
Hi Mark, > Hi Rutger, > > On Fri, 2005-05-06 at 07:24 -0700, Rutger Ovidius wrote: > > AH> I don't think that anyone is proposing to drop static libraries on > > AH> Win32. Win32 systems have their own requirements that make static > > AH> libs preferable in some cases. On GNU systems, however, static libs > > AH> make no sense at all for the Java language. > > > > One of the first things I had hoped for from gcj was static linking > > (except for libc) on GNU systems. > > > > There is new era of shared library hell and it seems to only apply to > > libgcj. > > I might be to young to have experienced this last era of share library > hell. Do you have a pointer to what you are referring to and how it was > solved back then on GNU systems? Example: Compile a C++ program on x86 Linux with gcc 2.9x, install it on a system with gcc 3.x As long as your program does not throw an exception, everything is fine. If your program throws an exception, the application crashes. Reason: /usr/lib/libstdc++.so You have to fiddle around with LD_PRELOAD, I found no other way. An unexperianced user is lost in space :-( Wolfgang Machen Sie aus 14 Cent spielend bis zu 100 Euro! Die neue Gaming-Area von Arcor - über 50 Onlinespiele im Angebot. http://www.arcor.de/rd/emf-gaming-1
Re: GCC 4.1: Buildable on GHz machines only?
Rutger Ovidius writes: > Friday, May 6, 2005, 8:06:49 AM, you wrote: > > AH> But Java isn't compatible with static linking. Java is, by its very > AH> nature, a dynamic language, where classes invoke and even generate > AH> other classes on the fly. There is no way when linking to determine > AH> what set of libraries is required. This is a simple fact, and no > AH> amount of declaring " this is what users want!" is going to change > AH> it. > > I didn't know that java had a nature. Now you do. > It has features. Some features will work when it is implemented in a > certain way and some won't. The set of features that work when linking statically is unspecified and changes over time, depending on implementation details within the library. If we wanted to come up with a new language subset compatible with static linkage we could do that, but it would be a substantial design effort and we'd need someone to do the work. Personally speaking, I don't think it's a very good idea, as a lot of the Java language as specified depends on dynamic linking, but I wouldn't obstruct someone who really wanted to do it. Andrew.
Re: Stage1 ?
Le Vendredi 06 Mai 2005 09:16, Eric Christopher a écrit : > On Fri, 2005-05-06 at 07:06 +0200, Stephane Wirtel wrote: > > Hi all, > > > > I would like to know how many stages are there ? > > > > What's the first stage ? > > http://gcc.gnu.org/develop.html > > -eric Thanks Eric
Re: GCC 4.1: Buildable on GHz machines only?
Friday, May 6, 2005, 9:14:31 AM, you wrote: AH> Rutger Ovidius writes: >> Friday, May 6, 2005, 8:06:49 AM, you wrote: >> >> AH> But Java isn't compatible with static linking. Java is, by its very >> AH> nature, a dynamic language, where classes invoke and even generate >> AH> other classes on the fly. There is no way when linking to determine >> AH> what set of libraries is required. This is a simple fact, and no >> AH> amount of declaring " this is what users want!" is going to change >> AH> it. >> >> I didn't know that java had a nature. AH> Now you do. Hallelujah! God is great. >> It has features. Some features will work when it is implemented in a >> certain way and some won't. AH> The set of features that work when linking statically is unspecified AH> and changes over time, depending on implementation details within the AH> library. The implementation details within the current library already allow the unspecified set of features to work when statically linked on win32. Chalk another one up to the big G. AH> If we wanted to come up with a new language subset compatible with AH> static linkage we could do that, but it would be a substantial design AH> effort and we'd need someone to do the work. Personally speaking, I AH> don't think it's a very good idea, as a lot of the Java language as AH> specified depends on dynamic linking, but I wouldn't obstruct someone AH> who really wanted to do it. I wasn't asking for a new language subset. I can understand that bestowing yet another nature on java would be a superhuman task. I wasn't asking for anything really. I was just expressing an opinion. Sorry for that.
Bug in multifile operation?
Per Bothner wrote:
Paolo Bonzini wrote: >> But what Per is talking about is how .o files
are built. This change
would probably not be very difficult fwiw; we already have done this
in a place or two where we've needed BC ABI support.
As long as libtool supports it, it should not be very difficult indeed.
It semi-supports it.
With @aaa.list it supports it, it seems. I made a patch, but it fails
because of a bug. It is enough to supply these two files together to jc1
package java.awt;
import java.util.EventObject;
public abstract class AWTEvent extends EventObject {}
package java.awt;
import java.awt.event.KeyEvent;
public class B {
Object[] o = KeyEvent.class.getFields();
}
I'm tracking the failure, so far it seems that, in find_in_imports for
java.awt.event.KeyEvent, there's already something different in the
IDENTIFIER_CLASS_VALUE for KeyEvent. But I have not understood where it
is set. :-(
Paolo
Re: GCC 4.1: Buildable on GHz machines only?
On 2005-05-06, at 18:14, Andrew Haley wrote: Rutger Ovidius writes: Friday, May 6, 2005, 8:06:49 AM, you wrote: AH> But Java isn't compatible with static linking. Java is, by its very AH> nature, a dynamic language, where classes invoke and even generate AH> other classes on the fly. There is no way when linking to determine AH> what set of libraries is required. This is a simple fact, and no AH> amount of declaring " this is what users want!" is going to change AH> it. I didn't know that java had a nature. Now you do. It has features. Some features will work when it is implemented in a certain way and some won't. The set of features that work when linking statically is unspecified and changes over time, depending on implementation details within the library. If we wanted to come up with a new language subset compatible with static linkage we could do that, but it would be a substantial design effort and we'd need someone to do the work. Personally speaking, I don't think it's a very good idea, as a lot of the Java language as specified depends on dynamic linking, but I wouldn't obstruct someone who really wanted to do it. You don't understand that it's perfectly valid to put PIC symbols inside an .a file. From the users perspective this may very well appear to be like static linkage. There are no principal reasons to shatter every single application in to a heap of .so files.
GCC4.0.0 - Query
Hi, I am currently working on GCC Instruction Scheduling pass. The previous versions of GCC, from GCC-3.3 onwards, had the provision to insert NOP-rtl appropriately during Instruction Scheduling pass(haifa.c : schedule_block). This is required for machine-architectures which do not support hardware-stall and requires compiler to insert NOP. However, GCC4.0.0 does not contain this code to insert NOP rtl. Is there any technical reason behind this? Can anyone please clarify about this matter? -- Regards, Sachin S.
Re: GCC 4.1: Buildable on GHz machines only?
On Fri, May 06, 2005 at 04:06:49PM +0100, Andrew Haley wrote: > Rutger Ovidius writes: > > Java is a simple language, used as the intro learning language in most > > universities that I know of. Not having to plan memory management like > > c++ motivates very fast development. Compiling small utils with it and > > having them be portable, even on GNU systems, is an incredible selling > > point. > > Is it really? There are users out there insane enough to be passing > around precompiled binaries of small utils? Yes. They're called "applets". They run in your web browser.
Re: GCC 4.1: Buildable on GHz machines only?
> "Matt" == Matt Thomas <[EMAIL PROTECTED]> writes: Matt> I'd like to libjava be split into multiple shared libraries. Matt> In C, we have libc, libm, libpthread, etc. In X11, there's X11, Xt, etc. Matt> So why does java have everything in one shared library? Could Matt> the swing stuff be moved to its own? Are there other logical Matt> divisions? This is possible, though it isn't completely trivial. To get the best effect at runtime, you want completely separate shared libraries, which aren't linked in by default. So then you need a mechanism to load these libraries dynamically. There are a few ways to implement this, but you have to be careful to let the test suite continue to work even if the user hasn't run "make install". I would suggest separating out AWT and Swing as a first test. Tom Fitzsimmons' patch to BC-compile these libraries will make this a lot simpler, as it already handles the weird special cases, and already breaks up the build along the required lines. Tom
Re: GCC 4.1: Buildable on GHz machines only?
> "David" == David Daney <[EMAIL PROTECTED]> writes: David> Perhaps the crazy person that only needs 2MB worth of the files from David> said static library when the corresponding shared library is David> 8MB. Especially if this lunatic is trying to make the program, OS David> kernel etc fit in an 8MB flash memory device. In general I think this thread is merging several issues that, while related, also require separate consideration: * Build times are too slow * Many programs that one might run on a Linux distro don't require all of libgcj.so; therefore it is too big * In some environments (including, surprisingly to me, Linux) it is convenient to ship a statically-linked-to-libgcj app * The humongosity of libgcj crushes embedded boxes In particular I think build times should ideally be addressed as a separate issue from deployment approaches, as the latter represent real user requirements, whereas the former can be turned into a collection of ad hoc hacks if need be. Splitting up libgcj.so probably makes sense even for the Linux distro case (the one I am most concerned with at the moment), just so that apps that don't use AWT or Swing don't really pay for it. The overhead of, say, BC-compiling AWT and putting it in a separate .so doesn't seem unreasonable, based on our experiences with BC compiling large apps. (Even this situation has its losers, for instance CNI users accessing AWT, like the xlib peers. It looks impossible to please everybody 100%.) This split would help Windows users, too, I think, as at least AWT and Swing are fairly useless on that platform (no native peers; you can run the Gtk peers but that is weird). For embedded platforms, I would not mind seeing patches to allow completely disabling parts of the build based on configure switches. E.g., a switch to drop AWT entirely would be fine by me. Someone would probably have to tend to this to prevent it breaking; I'd be reluctant to accept it as "fully supported" simply because I know I would never be building that way. (There is obviously some limit to how far this program could be carried; and at the extrema of customizability we would either need a radically different approach, or you would just have to accept that you need local changes.) FWIW, as far as splitting goes, I think it isn't just AWT/Swing, though those are the big ones. RMI and java.sql could probably be meaningfully broken off into separate libraries as well. It isn't clear how fine we should grind this. One actual conflict I foresee is that, as we compile more of the core library with -findirect-dispatch, it will get harder to use static linking sensibly. This is still a ways away, as the CNI problem has not yet been solved; and in any case exactly where the BC-ification will stop is still unknown. But, we have already started this and I think more will be showing up in the near future. Perhaps this can be solved by letting folks optionally compile libgcj with the C++ ABI. -whole-archive also "solves" this, though it eliminates the useful ability of static linking to drop the bits you aren't using (I think this is irreconcilable with how BC works). Our thinking has been that we would solve a lot of gcj problems with the BC ABI. And, in particular, once it is solid and complete, we would make it the default and then feel free to break C++ ABI compatibility even in minor releases; the idea being that this would be a way around the fact that GCC's release schedule is too slow for libgcj. I'm not sure what Plan B would be. Maybe separate libgcj releases somehow. Tom
Re: GCC 4.1: Buildable on GHz machines only?
--- Tom Tromey wrote: > I'm not sure what Plan B would be. Maybe separate > libgcj releases > somehow. You coulder consider just having GCJ inside GCC but somehow get it to use GNU Classpath directly, this would also reduce it needing to be re-sync with GNU Classpath (which I beleive libgcj is based on it) and allows you deliver a more up-to-date Java library to people faster. ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
new bounds-checking patches
I just released 2 new releases for gcc-3.3.6 and gcc-4.0.0 of my bounds-checking patch. The patches can be found on http://sourceforge.net/projects/boundschecking Can some one update the extension page (http://gcc.gnu.org/extensions.html). This page still points to http://web.inter.NL.net/hcc/Haj.Ten.Brugge/ Thanks. When implementing bounds-checking for gcc-4.0.0 I found perhaps a small mistake in the gimplify code. I applied the following patch: diff -rupN -x tags -x 'c-parse.[cy]' -x 'objc-parse.[cy]' -x 'parse.[ch]' -x '*.info*' gcc-4.0.0.org/gcc/gimplify.c gcc-4.0.0/gcc/gimplify.c --- gcc-4.0.0.org/gcc/gimplify.c2005-04-17 05:53:50.0 +0200 +++ gcc-4.0.0/gcc/gimplify.c2005-05-05 17:43:00.0 +0200 @@ -334,7 +334,7 @@ create_tmp_var_raw (tree type, const cha TYPE_ATTRIBUTES (new_type) = TYPE_ATTRIBUTES (type); tmp_var = build_decl (VAR_DECL, prefix ? create_tmp_var_name (prefix) : NULL, - type); + new_type); /* The variable was declared by the compiler. */ DECL_ARTIFICIAL (tmp_var) = 1; It looks like a typo. I can open a problem report is this is really a mistake. I also did some performance tests. The results are below. I selected a random package (openssl-0.9.7e.tar.gz) and ran the bounds-checking and mudflap implementations with different compiler opions. This is just one random package selection and I only wanted to show that my new inline implementation for gcc-4.0.0 worked well when compiling with -O3. Since mudflap is in this release as well I also did some tests there. I could have picked the wrong testcode to compare bounds-checking and mudflap. Herman. #! /bin/sh # gcc-4.0.0 with bounds-checking patch # compile slower run slower # normal-O2 : 114.651.0017.39 1.00 # normal-O3 : 119.391.0417.36 1.00 # -fbc-strings-only -O2 : 130.161.1433.64 1.93 # -fbc-strings-only -O3 : 137.081.2032.58 1.87 # -fbc-strings-only -O2 INL : 130.301.1434.05 1.96 # -fbc-strings-only -O3 INL : 137.201.2032.55 1.87 # -fbounds-checking -O2: 171.281.49 328.29 18.88 # -fbounds-checking -O3: 244.492.13 229.60 13.20 # -fbounds-checking -O2 INL : 338.902.96 244.59 14.06 # -fbounds-checking -O3 INL : 414.593.62 122.64 7.05 # gcc-4.0.0 with mudflap #compile slowerrun slower # normal-O2 : 115.401.0118.04 1.04 # normal-O3 : 120.341.0517.50 1.01 # -fmudflap -O2 : 338.922.96 206.08 11.85 # -fmudflap -O3 : 365.523.19 197.00 11.33 rm -f result log log2 exec >log 2>log2 FORMAT="%U user %S system %E elapsed %P CPU" PATH=$HOME/bounds/install/bin:$PATH # bounds-checking GCC_BOUNDS_OPTS="-no-message -no-statistics" ; export GCC_BOUNDS_OPTS GCC=gcc for i in "-O2" \ "-O3" \ "-fbc-strings-only -O2" \ "-fbc-strings-only -O3" \ "-fbc-strings-only -O2 -D__BOUNDS_INLINE__" \ "-fbc-strings-only -O3 -D__BOUNDS_INLINE__" \ "-fbounds-checking -O2" \ "-fbounds-checking -O3" \ "-fbounds-checking -O2 -D__BOUNDS_INLINE__" \ "-fbounds-checking -O3 -D__BOUNDS_INLINE__" do echo $i >> result gzip -cd openssl-0.9.7e.tar.gz | tar -xvf - cd openssl-0.9.7e /usr/bin/time -f "$FORMAT" -o ../result -a make CC="$GCC $i" CFLAG="-DOPENSSL_NO_KRB5" PERL=perl /usr/bin/time -f "$FORMAT" -o ../result -a make CC="$GCC $i" CFLAG="-DOPENSSL_NO_KRB5" PERL=perl test cd .. rm -rf openssl-0.9.7e done # mudflap MUDFLAP_OPTIONS="-no-timestamps -backtrace=0"; export MUDFLAP_OPTIONS GCC=gcc for i in "-O2" \ "-O3" \ "-fmudflap -lmudflap -O2" \ "-fmudflap -lmudflap -O3" do echo $i >> result gzip -cd openssl-0.9.7e.tar.gz | tar -xvf - cd openssl-0.9.7e /usr/bin/time -f "$FORMAT" -o ../result -a make CC="$GCC $i" CFLAG="-DOPENSSL_NO_KRB5" PERL=perl /usr/bin/time -f "$FORMAT" -o ../result -a make CC="$GCC $i" CFLAG="-DOPENSSL_NO_KRB5" PERL=perl test cd .. rm -rf openssl-0.9.7e done
Re: new bounds-checking patches
On Fri, 6 May 2005, Herman ten Brugge wrote: > I just released 2 new releases for gcc-3.3.6 and gcc-4.0.0 of my > bounds-checking patch. > The patches can be found on http://sourceforge.net/projects/boundschecking > > Can some one update the extension page (http://gcc.gnu.org/extensions.html). > This page still points to http://web.inter.NL.net/hcc/Haj.Ten.Brugge/ I'll make this change in a minute, but I'll note that the old page has no obvious reference to the new one nor does it automatically redirect -- had you set up the latter, I would have noticed this via my regular checks and updated in any case. Gerald
Re: How to get MIN_EXPR without using deprecated min operator
> The problem with C++ is in fold as we now have to disable the > optimization > which converted "a >= b ? b : a" to MIN_EXPR. Which begs the question of why it doesn't happen when we get into the tree optimizers and have lvalues there. r~
Missed optimizations: Constant propagation / algebraic simplification re-run after after reload.?
Hello,
when working on the AVR target I stepped over the follwoing issue (IMO not
urgent but still bearing quite some potential of improvement):
When implementing "lowering" of SImode and HImode expressions to QImode
sequences by splitters after reload, quite a number of new optimization
opportunities show up that presently are not realized. These would probably
require that some kind of constant propagation and algebraic simplification
would be re-run *after* reload.
A typical case are mixed-mode expressions like in the function
uint16_t
dummy (uint8_t y, uint32_t x)
{
return x & y;
}
which yields a RTL sequence like
(insn 32 8 13 0 (set (reg:QI 25 r25 [ y+1 ])
(const_int 0 [0x0])) 9 {*movqi} (nil)
(nil))
(insn 33 17 34 0 (set (reg:QI 24 r24 [ ])
(and:QI (reg:QI 24 r24 [orig:45 y ] [45])
(reg:QI 20 r20 [orig:43 x ] [43]))) 44 {andqi3} (nil)
(expr_list:REG_DEAD (reg:QI 20 r20 [orig:43 x ] [43])
(nil)))
(insn 34 33 26 0 (set (reg:QI 25 r25 [ +1 ])
(and:QI (reg:QI 25 r25 [ y+1 ])
(reg:QI 21 r21 [ x+1 ]))) 44 {andqi3} (nil)
(expr_list:REG_DEAD (reg:QI 21 r21 [ x+1 ])
(nil)))
. Here insn 34 could have been optimized away ( (0 & reg21) is always zero).
Such situation could not be identified before doing the splitting.
After seing such situation a couple of times in my application code, I am
wondering: ... Is there already a pass that implements a suitable kind of
algebraic simplification and constant propagation on the RTL level that could
be re-run after reload?
Alternatively: Is there a method how splitter patterns could find out whether
one of the register input operands maybe holds a known constant value?
Yours,
Björn
Re: Missed optimizations: Constant propagation / algebraic simplification re-run after after reload.?
>
> Hello,
>
> when working on the AVR target I stepped over the follwoing issue (IMO not
> urgent but still bearing quite some potential of improvement):
>
> When implementing "lowering" of SImode and HImode expressions to QImode
> sequences by splitters after reload, quite a number of new optimization
> opportunities show up that presently are not realized. These would probably
> require that some kind of constant propagation and algebraic simplification
> would be re-run *after* reload.
> A typical case are mixed-mode expressions like in the function
>
> uint16_t
> dummy (uint8_t y, uint32_t x)
> {
> return x & y;
> }
You should expand this at expand time instead as there are enough optimizations
before expand time to get to it optimized.
-- pinski
Re: new bounds-checking patches
Gerald Pfeifer wrote: On Fri, 6 May 2005, Herman ten Brugge wrote: I just released 2 new releases for gcc-3.3.6 and gcc-4.0.0 of my bounds-checking patch. The patches can be found on http://sourceforge.net/projects/boundschecking Can some one update the extension page (http://gcc.gnu.org/extensions.html). This page still points to http://web.inter.NL.net/hcc/Haj.Ten.Brugge/ I'll make this change in a minute, but I'll note that the old page has no obvious reference to the new one nor does it automatically redirect -- had you set up the latter, I would have noticed this via my regular checks and updated in any case. Gerald You are quick. I have updated the page and mention that ALL new releases will be on sourceforge. I am going to remove this site at the end of this year. Herman.
How can I write an empty conversion instruction
I was wondering if anyone could tell me how to write an (empty) instruction pattern that does a truncate/extend conversion on a register 'in place'. All the conversions I see are like this one in ia64/ia64.md: (define_insn "extendsfdf2" [(set (match_operand:DF 0 "fr_register_operand" "=f") (float_extend:DF (match_operand:SF 1 "fr_register_operand" "f")))] "" "fnorm.d %0 = %1" [(set_attr "itanium_class" "fmac")]) Where the source and the destination may or may not be the same register. I am trying to create an empty extend operation I can use to 'convert' a SFmode register into a DFmode register without actually generating any code. Since I don't want this extend called in place of the normal one I defined it as an UNSPEC operation instead of a float_extend operation and since it doesn't generate any code and it cannot move the result from one register to another I need to define it with only one operand. But my attempt to do this doesn't seem to work and I was wondering if anyone could tell me why or perhaps point me to an example of an instruction that does a conversion in place that might help me understand how to write such an instruction. My attempt: (define_insn "nop_extendsfdf" [(set (match_operand:DF 0 "fr_register_operand" "+f") (unspec:DF [(match_dup:SF 0)] UNSPEC_NOP_EXTEND))] "" "" [(set_attr "itanium_class" "ignore") (set_attr "predicable" "no") (set_attr "empty" "yes")]) I think the match_dup may be wrong since I am using it with SF but the original match_operand has DF. Do I need to make this modeless? Or is there some other way to create an empty conversion instruction. Steve Ellcey [EMAIL PROTECTED]
Re: How can I write an empty conversion instruction
On Fri, May 06, 2005 at 01:59:06PM -0700, Steve Ellcey wrote: > My attempt: > > (define_insn "nop_extendsfdf" > [(set (match_operand:DF 0 "fr_register_operand" "+f") > (unspec:DF [(match_dup:SF 0)] UNSPEC_NOP_EXTEND))] > "" > "" > [(set_attr "itanium_class" "ignore") >(set_attr "predicable" "no") >(set_attr "empty" "yes")]) > > I think the match_dup may be wrong since I am using it with SF but the > original match_operand has DF. Do I need to make this modeless? Or is > there some other way to create an empty conversion instruction. You might want to try this instead: [(set (match_operand:DF 0 "fr_register_operand" "=f") (unspec:DF [(match_operand:SF 0 "fr_register_operand" "0")] UNSPEC_NOP_EXTEND))] -- Daniel Jacobowitz CodeSourcery, LLC
Re: How can I write an empty conversion instruction
> Steve Ellcey writes: Steve> I was wondering if anyone could tell me how to write an (empty) Steve> instruction pattern that does a truncate/extend conversion on a register Steve> 'in place'. See extendsfdf2_fpr in rs6000.md David
Re: How can I write an empty conversion instruction
> You might want to try this instead: > > [(set (match_operand:DF 0 "fr_register_operand" "=f") > (unspec:DF [(match_operand:SF 0 "fr_register_operand" "0")] > UNSPEC_NOP_EXTEND))] > > -- > Daniel Jacobowitz > CodeSourcery, LLC Nope. GCC doesn't like seeing two match_operand's for op 0. Steve Ellcey [EMAIL PROTECTED]
Re: Missed optimizations: Constant propagation / algebraic simplification re-run after after reload.?
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>> Björn Haase <[EMAIL PROTECTED]> writes:
>> when working on the AVR target I stepped over the follwoing issue
>> (IMO not urgent but still bearing quite some potential of improvement):
>>
>> When implementing "lowering" of SImode and HImode expressions to QImode
>> sequences by splitters after reload, quite a number of new optimization
>> opportunities show up that presently are not realized. These would probably
>> require that some kind of constant propagation and algebraic simplification
>> would be re-run *after* reload.
>> A typical case are mixed-mode expressions like in the function
>>
>> uint16_t
>> dummy (uint8_t y, uint32_t x)
>> {
>> return x & y;
>> }
>
> You should expand this at expand time instead as there are enough
> optimizations before expand time to get to it optimized.
It would seem most ideal if GCC first lowered all operations to their
canonical minimal precision form prior to code generation, yielding:
(set (reg:hi ret) (zero_extend:hi (and:qi (reg:qi y) (subreg:qi x 0
Where then it may be expanded as most appropriate for an arbitrary target.
Re: How can I write an empty conversion instruction
On Fri, May 06, 2005 at 02:38:30PM -0700, Steve Ellcey wrote: > > You might want to try this instead: > > > > [(set (match_operand:DF 0 "fr_register_operand" "=f") > > (unspec:DF [(match_operand:SF 0 "fr_register_operand" "0")] > > UNSPEC_NOP_EXTEND))] > > > > -- > > Daniel Jacobowitz > > CodeSourcery, LLC > > Nope. GCC doesn't like seeing two match_operand's for op 0. Er, yeah, correct the second 0 to a 1. The point I was making was the "0" constraint instead of a match_dup. -- Daniel Jacobowitz CodeSourcery, LLC
successful build on i686-pc-cygwin
srcdir/config.guess: i686-pc-cygwin gcc -v: Using built-in specs. Target: i686-pc-cygwin Configured with: ../gcc-4.0.0/configure --verbose --prefix=/work/install --exec-prefix=/work/install --sysconfdir=/work/ install/etc --libdir=/work/install/lib --libexecdir=/work/install/lib --mandir=/work/install/man --infodir=/work/install /info --enable-languages=c,c++ --enable-nls --without-included-gettext --with-system-zlib --enable-interpreter --enable- threads=posix --enable-sjlj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry Thread model: posix gcc version 4.0.0 languages: c, c++ (used core and c++ sources only) additional information: Important to mount all binary folders with the -X option, as otherwise command-lines will be too long, for instance: mount -f -X c:/cygwin/bin /bin Important: This also goes for the executables built, so having your objdir inside a mount with cygexec enabled is required. j -- jørgen h. seland [EMAIL PROTECTED]
PowerPC DWARF2 information mismatch
On PowerPC, we have a test case which results in a mismatch between the register number used for the return address in the DWARF2 CIE and the FDE. That causes backtraces to go wonky. The test case is kinda big, but I'll post it when I get it cut down. In any case, I can sort-of explain what's going on, though my DWARF2-fu is very weak. I'd appreciate any insight on how this might be fixed. In the CIE, we have: .byte 0x41 # CIE RA Column In the FDE, we have: .byte 0x11 # DW_CFA_offset_extended_sf .uleb128 0x6c .sleb128 -1 The mismatch occurs because of the PowerPC use of different DWARF2 register numbers of EH and debug information. It looks like 0x41 is the right choice for EH information, but not debug information. The code that generates the FDEs has a "for_eh" parameter that allows it to decide, but the code for CIEs does not -- and so it cannot get it right. In more detail, register 65 (0x41) is GCC's internal register number for the link register: #define LINK_REGISTER_REGNUM 65 The use of register 65 is coming from: dw2_asm_output_data (1, DWARF_FRAME_RETURN_COLUMN, "CIE RA Column"); because rs6000.h does: #define DWARF_FRAME_RETURN_COLUMN DWARF_FRAME_REGNUM (LINK_REGISTER_REGNUM) /* Use gcc hard register numbering for eh_frame. */ #define DWARF_FRAME_REGNUM(REGNO) (REGNO) The use of register 108 comes from: case DW_CFA_offset_extended_sf: case DW_CFA_def_cfa_sf: r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh); dw2_asm_output_data_uleb128 (r, NULL); Here, the register number is again 65. But, #define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH) \ ((FOR_EH) ? (REGNO) \ : (REGNO) == CR2_REGNO ? 64 \ : DBX_REGISTER_NUMBER (REGNO)) and, in rs6000_dbx_register_number: if (regno == LINK_REGISTER_REGNUM) return 108; So, for non-EH, we get 108. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
gcc-3.4-20050506 is now available
Snapshot gcc-3.4-20050506 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050506/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050506 You'll find: gcc-3.4-20050506.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050506.tar.bz2 C front end and core compiler gcc-ada-3.4-20050506.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050506.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050506.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050506.tar.bz2 Java front end and runtime gcc-objc-3.4-20050506.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050506.tar.bz2The GCC testsuite Diffs from 3.4-20050429 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: PowerPC DWARF2 information mismatch
On May 6, 2005, at 7:48 PM, Mark Mitchell wrote: On PowerPC, we have a test case which results in a mismatch between the register number used for the return address in the DWARF2 CIE and the FDE. That causes backtraces to go wonky. The test case is kinda big, but I'll post it when I get it cut down. This sounds like PR 18655. -- Pinski
Re: PowerPC DWARF2 information mismatch
Andrew Pinski wrote: On May 6, 2005, at 7:48 PM, Mark Mitchell wrote: On PowerPC, we have a test case which results in a mismatch between the register number used for the return address in the DWARF2 CIE and the FDE. That causes backtraces to go wonky. The test case is kinda big, but I'll post it when I get it cut down. This sounds like PR 18655. Indeed, thanks. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
GCC 4.0.0 on i586-pc-linux-gnu: Bootstrap (C, C++) Success
Host: i586-pc-linux-gnu Hardware: AMD K6-II, 192MB RAM OS: Slackware 10.1, kernel: 2.6.11.7, glibc-2.3.4, binutils-2.15.92.0.2 Downloads: gcc-core-4.0.0, gcc-g++-4.0.0 Languages: C, C++ Target: i586-pc-linux-gnu Configured with: ../configure Thread model: posix gcc version 4.0.0 $ date > /gcc ; make bootstrap ; date >> /gcc $ cat /gcc Fri May 6 12:25:31 UTC 2005 Fri May 6 21:17:41 UTC 2005 So, it took about nine hours ;) Raul Tosa, Cluj-Napoca, Romania
Re: restrict and char pointers
Hi,
On Thu, 5 May 2005, Daniel Berlin wrote:
> You can do it, but apparently restrict isn't as simple as "a and b are
> both restrict pointers and therefore can never alias", because that's
> not the actual definition of restrict. It says stuff about pointers
> "based on" restricted objects, etc.
>
> Joseph Myers has shown some very weird but legal things you can do with
> restrict that make it all but pointless to try to handle, at least for
> the non function argument case.
Disagreement here. Some of Josephs weird examples were things like:
void f(int* restrict a, int * restrict b) {
for (i=0; i < N; i+=2) a[i] = 2*b[i];
}
int array[N];
f (&array[0], &array[1]);
I.e. interleaving the pointers in a way that they both point into the
same object. This is not forbidden by restrict, but it also poses no
problem. The two restrict pointers still may not actually point to the
same memory objects (individual array elements here), so the compiler can
still trivially apply the "two restrict pointers don't alias" rule.
Then there is the problem of "based on". This allows a non-restrict
pointer to sometimes alias a restrict pointer. One could ignore this
rule at first, for ease of implementation, and say that a unrestricted
pointer can alias everything again. restricted pointers themself can only
be based on other restricted pointers under very narrow circumstances,
which effectively prevents them again to be aliased at their points of
dereference.
User actually using restrict in their programs will most probably use
restrict for each pointer possible, so just handling that two restrict
pointers can't alias alone would probably catch 90% of all cases. (I've
actually had one user who was very confused that the vectorizer didn't do
anything on his very simple two-line function, although he made all three
pointer arguments be restricted).
As you said the most important would probably be to handle restrict
pointers in function arguments. I would add to that also those pointers
which are not used in any RHS of any statement (except for being
dereferenced of course). This would ensure that no other pointer is based
on them. And it would allow users to write code like:
void f(int* a, int *b, int n) {
if (a > b+n || b > a+n) { // arrays don't overlap
int * restrict ar = a;
int * restrict br = b;
/* Make this nonaliasing known to the compiler */
for (int i = 0; i < n; i++) ar[i] += br[i];
} else {
/* They overlap, can't optimize as much */
for (int i = 0; i < n; i++) a[i] += b[i];
}
}
Ciao,
Michael.
[RFC] Problem with altivec_vmrghb pattern in altivec.md
One of our internal apps fails due to problem in folding of vec_mergeh
of unsigned char of zeros and ones. It produces a new vector of zeros
followed
by ones. I traced the problem to the 3rd operand for the
"altivec_vmrghb" pattern defined in altivec.md file. It is 255 (0xff).
I think it
should be 21845 for unsigned chars (0x). With this change,
customer code passes and merged pattern looks OK.
So far so good. But I tried the following test case (with -O2) and
curiously enough it works OK with or *without* my change!. So, I am
wondering if
I approached this problem correctly.
From the code in simplify-rtx.c where value of merge of two constants
in a VEC_MERGE rtl is computed, it seems that the correct value for
element
selection should be 0x. But I am curious why changing this value
did not make a difference in the following test case (compiled with
-O2).
- Thanks, fariborz ([EMAIL PROTECTED])
#include
int main (int argc, const char * argv[]) {
vector unsigned char v_zero;
vector unsigned char v_c1;
v_zero = (vector unsigned char)
('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p');
v_c1 = (vector unsigned char)
('1','2','3','4','5','6','7','8','1','2','3','4','5','6','7','8');
vector unsigned char vResult = vec_mergeh(v_zero, v_c1);
printf ("\t%vc\n", vResult);
return 0;
}
Re: Missed optimizations: Constant propagation / algebraic simplification re-run after after reload.?
On Fri, May 06, 2005 at 10:18:15PM +0200, Björn Haase wrote: > When implementing "lowering" of SImode and HImode expressions to QImode > sequences by splitters after reload, quite a number of new optimization > opportunities show up that presently are not realized. No, the real problem is representational. We should be exposing this earlier. I'll post something about this shortly... r~
Re: How can I write an empty conversion instruction
On Fri, May 06, 2005 at 01:59:06PM -0700, Steve Ellcey wrote: > I was wondering if anyone could tell me how to write an (empty) > instruction pattern that does a truncate/extend conversion on a register > 'in place'. > > All the conversions I see are like this one in ia64/ia64.md: > > (define_insn "extendsfdf2" > [(set (match_operand:DF 0 "fr_register_operand" "=f") > (float_extend:DF (match_operand:SF 1 "fr_register_operand" "f")))] > "" > "fnorm.d %0 = %1" > [(set_attr "itanium_class" "fmac")]) > > Where the source and the destination may or may not be the same > register. The best way is to have a post-reload splitter that splits the insn into nothing at all. r~
