llvm dev - Sep 2009 - [LLVMdev] loads from a null address and optimizations

On Sun, Sep 6, 2009 at 3:53 PM, Kenneth Uildriks<kennethuil at gmail.com>
wrote:
> On Sun, Sep 6, 2009 at 5:32 PM, Eli Friedman<eli.friedman at
gmail.com> wrote:
>> On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at
gmail.com> wrote:
>>> It would be unfortunate in a way if "this instruction can trap
and go
>>> there" is taken to mean "if this instruction has no
effect other than
>>> a possible trap, the instruction and the trapping behavior *must*
be
>>> preserved".
>>
>> 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?

-Eli

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.

Ciao,

Duncan.

Eli Friedman wrote:
> On Sun, Sep 6, 2009 at 3:53 PM, Kenneth Uildriks<kennethuil at
gmail.com> wrote:
>> On Sun, Sep 6, 2009 at 5:32 PM, Eli Friedman<eli.friedman at
gmail.com> wrote:
>>> On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at
gmail.com> wrote:
>>>> It would be unfortunate in a way if "this instruction can
trap and go
>>>> there" is taken to mean "if this instruction has no
effect other than
>>>> a possible trap, the instruction and the trapping behavior
*must* be
>>>> preserved".
>>> 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?
We faced this problem in gcc, and unfortunately Java and Ada have different
properties when it comes to trapping instructions: Java must throw a
NullPointerException at the appropriate place, but AIUI Ada may or may not.

Andrew.

Hi Andrew,
> We faced this problem in gcc, and unfortunately Java and Ada have different
> properties when it comes to trapping instructions: Java must throw a
> NullPointerException at the appropriate place, but AIUI Ada may or may not.
in the case of Ada, throwing an exception at the appropriate place is
always fine.  The language standard does allow the compiler to perform
some optimizations which may result in the exception being thrown
somewhere else, but of course the compiler isn't obliged to perform
these optimizations.  In summary: it is always right to throw the
exception at the obvious place, but it is not necessarily wrong if it is
thrown somewhere else.

Ciao,

Duncan.