llvm dev - Apr 2015 - [LLVMdev] RFC: implicit null checks in llvm

On Thu, Apr 23, 2015 at 3:31 PM, Andrew Trick <atrick at apple.com>
wrote:
>
> It would be really nice to just emit a label next to an instruction and
> assume the stackmap entry will end up at the right address. I don’t think
> the backend can make that guarantee. Any Machine pass can insert
> instructions wherever it wants without looking for labels.
>
> I think labels are only employed just before code emission. Is there any
> existing example of labels being used earlier (I think GCRootLowering is
> the earliest)?
>
SelectionDAGBuilder::lowerInvokable() inserts EH_LABELs into the DAG for
normal invokes, and it more or less works out.

I don't know much about what transformations MI passes typically do, but my
guess is that you're concerned that some pass might re-schedule possibly
trapping operations inside the label range?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150423/4108f5ca/attachment.html>

> On Apr 23, 2015, at 4:07 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> On Thu, Apr 23, 2015 at 3:31 PM, Andrew Trick <atrick at apple.com
<mailto:atrick at apple.com>> wrote:
> It would be really nice to just emit a label next to an instruction and
assume the stackmap entry will end up at the right address. I don’t think the
backend can make that guarantee. Any Machine pass can insert instructions
wherever it wants without looking for labels.
> 
> I think labels are only employed just before code emission. Is there any
existing example of labels being used earlier (I think GCRootLowering is the
earliest)?
> 
> SelectionDAGBuilder::lowerInvokable() inserts EH_LABELs into the DAG for
normal invokes, and it more or less works out.
> 
> I don't know much about what transformations MI passes typically do,
but my guess is that you're concerned that some pass might re-schedule
possibly trapping operations inside the label range?
The scheduler itself doesn’t move anything around labels. But any pass can
perform code motion or load/store optimization. Also, any pass can insert an
instruction, like a copy, between the label and the load.

I’m not really sure how EH_LABEL ends up translating into exception tables, but
my guess is that it’s encoding a range that may include any arbitrary
instructions as long as the call is within the range. So as long as calls aren’t
reordered with labels and appears to have side effects it would work.

So, you could add a different kind of stack map entry that encodes ranges
instead of exact addresses, then survey all passes to ensure they don’t optimize
loads across labels. I would have more confidence doing this with a pseudo
instruction though.

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150423/1d66cc01/attachment.html>

On Thu, Apr 23, 2015 at 5:17 PM, Andrew Trick <atrick at apple.com> wrote:
> The scheduler itself doesn’t move anything around labels. But any pass can
> perform code motion or load/store optimization. Also, any pass can insert
> an instruction, like a copy, between the label and the load.
>
> I’m not really sure how EH_LABEL ends up translating into exception
> tables, but my guess is that it’s encoding a range that may include any
> arbitrary instructions as long as the call is within the range. So as long
> as calls aren’t reordered with labels and appears to have side effects it
> would work.
>
> So, you could add a different kind of stack map entry that encodes ranges
> instead of exact addresses, then survey all passes to ensure they don’t
> optimize loads across labels. I would have more confidence doing this with
> a pseudo instruction though.
>
I guess your concern is that you need an exact address to do patching.

If this feature is limited to simply allow handling exceptions raised from
loads and stores, then I'm not worried about copies, adds, or other code
being moved into the label range. We don't support catching traps from
those kinds of instructions. I'm only worried about memory accesses being
moved into the range. If we can address that, I think the EH_LABEL approach
works, and it generalizes to other trapping instructions like division or
FP exceptions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150424/e122c912/attachment.html>