[LLVMdev] loads from a null address and optimizations

Duncan Sands baldrick at free.fr
Sun Sep 6 22:04:22 PDT 2009

Hi Eli,

>>> What exactly would the semantics be if the instruction *might* trap?
>>> I somehow can't imagine it being useful.
>>> -Eli
>> I'm not sure I understand the question.  Instructions that are
>> guaranteed to trap can be optimized into unconditional traps.  So
>> we're talking about instructions that *might* trap in any case.
>> I was saying that if the only possible effect of an instruction is a
>> trap, do we really want optimizers to preserve it in every case?
> Right... the question is, is there any language that actually has such
> semantics?

before every operation, the Ada front-end generates code that checks
for out-of-bound array accesses, null pointer dereference, integer
overflow etc (whatever is appropriate for the operation) and throws
an exception if the error occurs.  It would be nice if the compiler
could turn these explicit checks into more efficient implicit checks.
For example, on a platform on which load/store to a null pointer will
send a signal to the program, the explicit null checks could be
removed since the Ada runtime knows how to magically convert the signal
into an exception thrown at the right place.  That said, the compiler
mustn't move around the load/store in a way that it wouldn't have done
if the explicit checks were present.



More information about the llvm-dev mailing list