This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch: gcj optimizations
- From: Tom Tromey <tromey at redhat dot com>
- To: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Java Patch List <java-patches at gcc dot gnu dot org>
- Date: 01 Dec 2001 13:13:56 -0700
- Subject: Re: Patch: gcj optimizations
- References: <874rnct3dv.fsf@creche.redhat.com> <3C082E3B.6070809@waitaki.otago.ac.nz>
- Reply-to: tromey at redhat dot com
>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
Bryce> I would like to see a more "generic" framework for doing
Bryce> this. That is, instead of having identifiers in
Bryce> JTI_GLOBAL_TREES
I agree. Modifying JTI_GLOBAL_TREES and the like is a pain.
I've updated my patch to do this. It's not quite ready to send yet
though.
Bryce> I thought things like __builtin_cos would fall back on the
Bryce> library function if the builtin wasn't implemented? In any case
Bryce> it ought to be possible for GCJ to find out if a given builtin
Bryce> has been registered.
Yes, you're right.
But as it stands right now the builtins are never registered. The
registration is only done for the C family of front ends. The whole
builtin mechanism seems tied pretty closely to the C view of the world
:-(. For instance you have to read builtin-types.def to process
builtins.def. But the former references stuff that is unknown and
useless to Java, like `complex_long_double_type_node'. We can fix or
work around this, I think. In doing this I've duplicated an
uncomfortably large amount of code. Ideally we'd share with the C
front ends, but there are enough minor differences that this may not
be possible. It's a mess.
Tom