This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Libjava failures status


> Jan Hubicka wrote:
> 
> >>It would be nice if we could avoid pessimising this too much. eg given:
> >>
> >>a = foo.a;
> >>b = foo.b;
> >>
> >>Then obviously the second load from foo can not trap. I assume that 
> >>would allow for larger BBs and that is good for optimization.
> >>
> >
> >Concerning the memory traps, Java has references and bounding checks on 
> >arrays.
> >How can one even access trapping memory in Java?
> >
> 
> "foo" could be a null pointer: NullPointerException.
Aha.  But then Java should probably generate checks, as foo.b may not trap in
case foo is large enought and NULL pointer area small enought.
So basically we are relying on the NULL pointer references to trap and
other references may not trap?

It may be worthwhile to teach null pointer check ellimination pass to remove
traps from instructions already checked, but I am not sure how to avoid compiler
from reordering these later.  Perhaps even the EH edge is enought.

Perhaps such a ellimination should be better done now at AST level in case AST
branch is going to get merged this development period - and I hope so
and Java is using function-at-time.

Honza
> 
> regards
> 
> Bryce.
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]