remove deprecated REG_LIBCALL / REG_RETVAL from sh.md (Was Re:
Fri Aug 13 18:13:00 GMT 2004
On Friday 13 August 2004 16:43, Joern Rennecke wrote:
> > Floating point .. what?
> Floating point operations that are explicit in what they do.
> I.e. instead of a (set (reg (call ...))), you see the actual operation
> being performed.
What would you want to know this for when you already have expanded to
RTL? Which cases do you know of that are not already properly handled
at the tree level?
I believe the focus should be on doing as much as possible on trees so
that the RTL passes have no need to know the actual operation that a
Perhaps you have can have new RTXes that would be replaced with
calls later on, in the cases where would RTL really have to know.
(shot-in-the-dark: UNSPEC with a define_insn_and_split? Perhaps
even generic RTX codes for the most common operations?)
> > Libcall notes where at one time the only way to have sequences of
> > instructions moved out of loops, when there was no PRE and only loop.c
> > to do loop invariant code motion. We now move almost all loop invariant
> > code at the tree level, some more bits in gcse.c's PRE, loop-invariant.c
> > can take care of everything else (though we might still need to teach it
> > to hoist MEMs).
> But gcse.c is still an RTL optimizer.
Well duh. A whole bunch of them even! gcse.c, my favorite mammoth :-)
But most, if not all, loop invariant code that is visible at the tree
level is moved there (there's a PRE and a LICM pass fortrees). That
was one of the major reasons to have tree optimizers the first place.
What's left to be done on the RTL level should be things like address
arithmetic, or stuff that some of the uglier expanders spit out (expand
is not transparent, I'd like to see us lower further at the tree level
so that the expanders can be simpler and more transparent).
Note, that gcse.c is already not very useful anymore. With the proper
alias analysis and load PRE in place (both are in the works), I expect
we can start looking into simplifying it a lot, or even removing it
> Have you tried this with software floating point? Do they all pass
> builtins-18.c with software floating point?
I did try soft float at the time yes (hi Paul :-). Soft float support
is not great on amd64. But this test case passes (as do many others):
Test Run By stevenb on Fri Aug 13 18:30:49 2004
Native configuration is x86_64-unknown-linux-gnu
=== gcc tests ===
Schedule of variations:
Running target unix/-msoft-float
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /space/stevenb/mainline/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /space/stevenb/mainline/gcc/testsuite/gcc.dg/dg.exp ...
Executing on host: /space/stevenb/build/gcc/xgcc -B/space/stevenb/build/gcc/ /space/stevenb/mainline/gcc/testsuite/gcc.dg/builtins-18.c -O2 -ffast-math -lm -msoft-float -o builtins-18.exe (timeout = 300)
PASS: gcc.dg/builtins-18.c (test for excess errors)
testcase /space/stevenb/mainline/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds
=== gcc Summary ===
# of expected passes 1
Same on i686.
> > I find it hard to believe that you, now, all of a sudden, need libcall
> > notes to get registers right. That was never their purpose, and it is
> > not how any other backend uses libcall notes at present.
> No, I am saying that loop optimizations are not the only ones that
> want to know the meaning of an operation, rather than its low-level coding.
What are those other ones, and why?
> We might eventually get to the point where the REG_LIBCALL / REG_RETVAL
> notes are indeed no longer needed, but I don't think we are quite there
Well, perhaps you can try and see if we're there already. And at least
try to remove them when we know they serve no purpose anymore.
Have you looked at the code that's generated with Toshi's patch?
More information about the Gcc-patches