This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Emit Constants, not ScalarExprs, for "immediate"-constrained inlineasm arguments.
ClosedPublic

Authored by ab on Jun 4 2015, 2:13 PM.

Details

Summary

Same problem as D10045 / PR23517, slightly different solution.

For inline assembly immediate constraints, we currently always use EmitScalarExpr, instead of directly emitting the constant. When the overflow sanitizer is enabled, this generates overflow intrinsics instead of constants.

Instead, emit a constant for constraints that either require an immediate (e.g. 'I' on X86), or only accepts constants (immediate or symbolic; i.e., don't accept registers or memory, I think).

(re-send on cfe-commits of D10254)

Diff Detail

Repository
rL LLVM

Event Timeline

ab updated this revision to Diff 27147.Jun 4 2015, 2:13 PM
ab retitled this revision from to [CodeGen] Emit Constants, not ScalarExprs, for "immediate"-constrained inlineasm arguments..
ab updated this object.
ab edited the test plan for this revision. (Show Details)
ab added reviewers: dsanders, ahatanak, t.p.northover.
ab added a subscriber: Unknown Object (MLST).

This patch looks fine to me.

Do we have to handle an expression like (long)&object - (long)&base when it's used with constraint "i"? I believe clang currently cannot handle this expression.

dsanders edited edge metadata.Jun 8 2015, 2:06 AM

I'm wondering if the assert ought to be a normal error message and I think we may need a REQUIRES for buildbots lacking sanitizer support but apart from that this patch LGTM.

Just to mention it, there's something odd about the 'i' constraint in the backends but I haven't had chance to investigate it yet. For some reason, it has to be handled in *DAGToDAGISel::SelectInlineAsmMemoryOperand() despite not being a memory operand.

lib/CodeGen/CGStmt.cpp
1759–1760 ↗(On Diff #27147)

Should this cause an error to be emitted on release builds too?

test/CodeGen/inline-asm-immediate-ubsan.c
2 ↗(On Diff #27147)

Sanitizers aren't always available. It's possible we need a 'REQUIRES:' line to disable the test for some buildbots.

ab added a comment.Jun 8 2015, 9:41 AM

Do we have to handle an expression like (long)&object - (long)&base when it's used with constraint "i"? I believe clang currently cannot handle this expression.

Yes, I don't think 'i' supports that.

Just to mention it, there's something odd about the 'i' constraint in the backends but I haven't had chance to investigate it yet. For some reason, it has to be handled in *DAGToDAGISel::SelectInlineAsmMemoryOperand() despite not being a memory operand.

I'm not too familiar with inline-asm handling, but could it be because it supports symbols, and symbols aren't really immediates (e.g. aren't usually supported in non-addressing mode contexts) ?

lib/CodeGen/CGStmt.cpp
1759–1760 ↗(On Diff #27147)

I'm not sure, my understanding of clang is, by the time we get to IR gen, source errors have already been caught and reported.

test/CodeGen/inline-asm-immediate-ubsan.c
2 ↗(On Diff #27147)

That makes sense for runtime tests, but is it necessary for codegen tests? I thought all of IR gen was always available, much like targets.

LGTM

In D10255#184893, @dsanders wrote:
Just to mention it, there's something odd about the 'i' constraint in the backends but I haven't had chance to investigate it yet. For some reason, it has to be handled in
*DAGToDAGISel::SelectInlineAsmMemoryOperand() despite not being a memory operand.

I'm not too familiar with inline-asm handling, but could it be because it supports symbols, and symbols aren't really immediates (e.g. aren't usually supported in non-addressing mode
contexts) ?

Possibly, but it could also be unintentional and just happened to turn out ok in the end. I noticed it while removing a hardcoded 'm' that caused all memory constraints to behave like 'm'.

lib/CodeGen/CGStmt.cpp
1759–1760 ↗(On Diff #27147)

I've just tried it on X86 with 'I' and it does emit an error so something else must be handling it.

test/CodeGen/inline-asm-immediate-ubsan.c
2 ↗(On Diff #27147)

I seem to remember it reporting errors early for some reason. I've just tried it and codegen is working without working sanitizers being available.

This revision was automatically updated to reflect the committed changes.