This is the mail archive of the
mailing list for the GCC project.
Re: CFG and libcall conflict for java
> On Monday, September 24, 2001, at 08:18 PM, Jim Wilson wrote:
> >The ia64-java compiler is not working because of a conflict between the
> >relatively new CFG code, and the LIBCALL/RETVAL support that we have had
> >for a while. We get a segfault in flow for some testcases.
> >The problem arises because java uses -fnon-call-exceptions. IA-64 does
> >not have a divide instruction, so divides are implemented as libcall
> >sequences. A divide traps, so these libcall sequences can throw. A
> >that can throw ends a basic block. We thus get libcall sequences that
> >a basic block boundary in the CFG.
I believe correct way is to emit those divides as normal calls, not libcalls,
as libcalls are not allowed to throw nor span the basic block boundary.
Can they really throw? (ie the sofware emulation creates some trap when division
Does Java standard require the trap to happen?
With midlevel RTL/AST branch we should be able to optimize still well enought,
as the DCE will be done earlier.
> >I am not very familiar with the new CFG support. However, my suspicion
> >that the only good way to solve the problem (without a higher IL) is
> >to make the CFG code aware that edges inside libcalls are special.
> >Perhaps a new EDGE_ABNORMAL_LIBCALL flag bit for CFG edges. Then
Speaking only about the problem of reordering basic blocks, we have similar
problem after setjmp/longjmp - the trick is probably to make the fallthru edge
from call abnormal, so the CFG code won't try to do something with it.
Problem remains, that we do have (and going to have more) code that must be libcall
aware - such as dead code removal in flow.c and works per basic block level. Then it
will not be aware of libcall starting in previous block and fail.
Richard, what do you think?
> >every optimization pass that makes use of the CFG needs to be modified
> >to be aware of these EDGE_ABNORMAL_LIBCALL edges, and handle them
> >specially. I do not know if this is feasible, or how much work it would
> >be if it was feasible. Additionally, code that knows how to optimize
> >away libcall sequences may need to be aware of the CFG, since deleting a
> >libcall may modify the CFG. I think this part would not be too hard.
> >Comments anyone? The ia64 java compiler is broken, so we do need some
> >of fix. At the moment, the only working fix I have is one that disables
> >REG_LIBCALL/REG_RETVAL notes when they cause trouble, and this is
> >because it causes a performance regression. But if we can't easily fix
> >CFG code, then I may have to go with this patch to get the java compiler
> >working again.