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

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

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?

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