X86TargetLowering::LowerAsmOperandForConstraint had better support than
TargetLowering::LowerAsmOperandForConstraint for arbitrary depth
getelementpointers for "i", "n", and "s" extended inline assembly
constraints. Hoist its support from the derived class into the base
class.
Details
- Reviewers
echristo t.p.northover - Commits
- rZORG23f5e7549435: [TargetLowering] Handle multi depth GEPs w/ inline asm constraints
rZORGeb3371a2bb45: [TargetLowering] Handle multi depth GEPs w/ inline asm constraints
rG23f5e7549435: [TargetLowering] Handle multi depth GEPs w/ inline asm constraints
rGeb3371a2bb45: [TargetLowering] Handle multi depth GEPs w/ inline asm constraints
rGc33f754e747b: [TargetLowering] Handle multi depth GEPs w/ inline asm constraints
rL360604: [TargetLowering] Handle multi depth GEPs w/ inline asm constraints
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 31414 Build 31413: arc lint + arc unit
Event Timeline
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
3512 | I think this needs to be uint64_t since the arithmetic SDNodes naturally have 2s-complement behaviour. The final value will still be interpreted in a signed manner, but intermediate calculations need to be define when wrapping. | |
3524 | With the above suggestion, I think you'll need to make sure this extension happens properly. You probably do anyway -- the code below for combining constants can do strange things to the high bits if pointer size is less than i64. |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
3524 | Thanks for the review. I'm sorry, but I don't fully understand this comment. Can you please provide more information or clarification? Are you suggesting maybe returning early if Offset + C->getSExtValue() is greater than INT_MAX? |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
3524 | All arithmetic is performed at 64-bits, and the final result is provided at that width. But if the original computation is 32-bits, I think bad things might happen. Consider: (add (sub X:i32, 1), -1) I think that leaves Offset as 0xfffffffe because of the odd combination of zero-extending the input and multiplying it by -1 for ISD::SUB. Effectively, some -1s are at 32-bits and some are at 64-bits. So I think you need to do a manual extension of Offset from Op.getValueType().getSizeInBits() (not looked up the API, but you get the idea) to i64 before creating the constant. |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
3524 |
Can you please walk me through the arithmetic on that (I might be mixing up my 2's compliment arithmetic, or order of operations)? |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
3524 | Also, it looks like SelectionDAG::FoldConstantArithmetic() could help here. |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
3524 | Ok, I agree that we should be Sign extending, not Z extending. SelectionDAG::FoldSymbolOffset seems to agree (or have the same misunderstanding). @srhines also points out I dropped the commutative nature of the pre-existing code, so I'll add that back in. |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
3524 | ok, I've switched to SExt from ZExt (as per SelectionDAG::FoldSymbolOffset). @t.p.northover can you please triple check? |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
3518 | Maybe I should initialize C to nullptr and then keep the C ? SDLoc(C) : SDLoc()? I'm not verify familiar with SDLoc, but it seems that I'm potentially messing up debug info? Should the previous code be constructing empty SDLocs (as opposed to SDLoc(GA)? |
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
3530 | Good catch, thank you. How's that look? Any thoughts on my SDLoc comment, above? |
I think this needs to be uint64_t since the arithmetic SDNodes naturally have 2s-complement behaviour. The final value will still be interpreted in a signed manner, but intermediate calculations need to be define when wrapping.