[LLVMdev] RFC: implicit null checks in llvm
Andrew Trick
atrick at apple.com
Wed Apr 29 18:52:41 PDT 2015
> On Apr 24, 2015, at 4:14 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>
> I don't think we can expose the memory operations directly from a
> semantic, theoretical point of view. Whether practically we can do
> this or not is a different question.
>
> Does LLVM do optimizations like these at the machine instruction
> level?
>
>
> if (condition)
> T = *X // normal load, condition guards against null
>
> EH_LABEL // clobbers all
> U = *X // implicit null check, branches out on fault
> EH_LABEL // clobbers all
> ...
>
> =>
>
> since the second "load" from X always happens, X must be
> dereferenceable
>
>
> T = *X // miscompile here
>
> EH_LABEL // clobbers all
> U = *X // implicit null check, branches out on fault
> EH_LABEL // clobbers all
> ...
>
> The fundamental problem, of course, is that we're hiding the real
> control flow which is
>
> if (!is_dereferenceable(X)) branch_out;
> U = *X
That’s a good description of the problem.
Lowering to real loads will *probably* just work because your are being saved by EH_LABEL instructions which are conservatively modeled as having unknown side effects. The feature that saves you will also defeat optimization of those loads. I don't see any advantage of this in terms of optimizing codegen. It is just a workaround to avoid defining pseudo instructions.
The optimal implementation would be to leave the explicit null check in place. Late in the pipeline, just before post-ra scheduling, a pass would combine and+cmp+br+load when it is profitable using target hooks like getLdStBaseRegImmOfsWidth(). Note that we still have alias information in the form of machine mem operands.
You could take a step in that direction without doing much backend work by lowering to pseudo-loads during ISEL instead of using EH_LABEL. Then the various load/store optimizations could be taught to explicitly optimize normal loads and stores over the pseudo loads but not among them.
Andy
More information about the llvm-dev
mailing list