This is an archive of the discontinued LLVM Phabricator instance.

[AVX512][inline-asm] Fix AVX512 inline assembly instruction resolution when the size qualifier of a memory operand is not specified explicitly.
ClosedPublic

Authored by coby on Nov 13 2016, 5:51 AM.

Details

Summary

This commit handles cases where the size qualifier of an indirect memory reference operand in Intel syntax is missing (e.g. "vaddps xmm1, xmm2, [a]").

GCC will deduce the size qualifier for AVX512 vector and broadcast memory operands based on the possible matches:
"vaddps xmm1, xmm2, [a]" matches only “XMMWORD PTR” qualifier.
"vaddps xmm1, xmm2, [a]{1to4}" matches only “DWORD PTR” qualifier.

This is different from the current behavior of LLVM, which deduces the size qualifier based on the size of the memory operand.
For "vaddps xmm1, xmm2, [a]"
"char a;" will imply "BYTE PTR" qualifier
"short a;" will imply "WORD PTR" qualifier.

This commit aligns LLVM to GCC’s behavior.

This is the LLVM part of the review.
The Clang part of the review: https://reviews.llvm.org/D26587

Differential Revision: https://reviews.llvm.org/D26586

Diff Detail

Repository
rL LLVM

Event Timeline

coby updated this revision to Diff 77740.Nov 13 2016, 5:51 AM
coby retitled this revision from to [X86][AVX512][InlineASM][MS][llvm] (I|G)CC Memory adjustments compatibility.
coby updated this object.
coby added reviewers: m_zuckerman, delena, rnk.
coby set the repository for this revision to rL LLVM.
coby added a subscriber: llvm-commits.
coby updated this object.Nov 13 2016, 5:54 AM
coby added a reviewer: myatsina.
myatsina added inline comments.Nov 17 2016, 9:56 AM
lib/Target/X86/AsmParser/X86AsmParser.cpp
769 ↗(On Diff #77740)

Please add description above the function.

1179 ↗(On Diff #77740)

I think this name is a but misleading.
How about "KeepMemUnsized" or "AllowBetterSizeMatch"?

1209 ↗(On Diff #77740)

Please clang-format your patch.
handle --> Handle

1211 ↗(On Diff #77740)

then --> than

2858 ↗(On Diff #77740)

why the break? why not put the inquiring logic here?
Is there some other code path that might reach the inquiring logic?

2895 ↗(On Diff #77740)

Why the break?

2959 ↗(On Diff #77740)

pan?

2998 ↗(On Diff #77740)

online --> only ?

3000 ↗(On Diff #77740)

a

3000 ↗(On Diff #77740)

Ignore this comment :)

coby updated this revision to Diff 78680.Nov 20 2016, 5:00 PM
coby marked 7 inline comments as done.Nov 20 2016, 5:02 PM
delena added inline comments.Nov 20 2016, 11:17 PM
lib/Target/X86/AsmParser/X86AsmParser.cpp
2848 ↗(On Diff #78680)

Put "assert" instead of "if".

2885 ↗(On Diff #78680)

IA allows only one memory operand per instruction.
if (UnsizedMemOp) {

UnsizedMemOpNext = X86Op;
break;

}
UnsizedMemOp = X86Op;

coby added inline comments.Nov 20 2016, 11:54 PM
lib/Target/X86/AsmParser/X86AsmParser.cpp
2848 ↗(On Diff #78680)

Cannot assert at this point. This function is called regardless of the platform.

2885 ↗(On Diff #78680)

Previous revision addressed this issue exactly, and was rejected. I found it redundant (and wrong) to continue looking past the first interception of an unsized mem op.
Having said that - both approaches are congregated to the same behavior.
If Marina won't furthermore object - I'm keen to revert to previous approach.

myatsina accepted this revision.Nov 21 2016, 6:11 AM
myatsina edited edge metadata.

LGTM (in condition you'll fix the typos and return to the break as Elena mentioned).

Also,
please clarify the summary of this review.

lib/Target/X86/AsmParser/X86AsmParser.cpp
1209 ↗(On Diff #77740)

Still relevant:
handle --> Handle

771 ↗(On Diff #78680)

Rephrase (don't forget to clang-format):

Obtain an appropriate size qualifier, when the AVX512 vector/broadcast memory operand is missing a qualifier.

2885 ↗(On Diff #78680)

If we're returning the break then please add a comment that we handle here only cases that have one undefined memory operand, and if an instruction has more than one memory operand we will fail later on when we'll try to match an instruction.

2955 ↗(On Diff #78680)

te --> the

This revision is now accepted and ready to land.Nov 21 2016, 6:11 AM
coby updated this revision to Diff 78717.Nov 21 2016, 6:51 AM
coby updated this object.
coby edited edge metadata.
coby retitled this revision from [X86][AVX512][InlineASM][MS][llvm] (I|G)CC Memory adjustments compatibility to [AVX512][inline-asm] Fix AVX512 inline assembly instruction resolution when the size qualifier of a memory operand is not specified explicitly..Nov 22 2016, 12:52 AM
coby updated this object.
This revision was automatically updated to reflect the committed changes.
rnk edited edge metadata.May 4 2017, 8:43 AM

I feel like we need to step back and ask why we are using the variable size information provided by the frontend at all. I don't think MSVC uses it. We probably only needed it because our intel asm matcher couldn't cope with ambiguity before and it was getting the wrong sizes.

I'm going to look into removing the frontend-directed AOK_SizeDirective rewrite altogether.

llvm/trunk/lib/Target/X86/AsmParser/X86AsmParser.cpp
1208

It seems ridiculous to emit this size directive modification here and then rewrite it later in the asm matcher. Surely there is a better way to do this.

1210

This code is not properly indented, and this actually confused me while reading the committed code.

1213

typo on "mechanism"

1504

We are always parsing inline asm when calling CreateMemForInlineAsm, that's why we're here.

2845

This seems unnecessary, which makes sense because your follow-up change D32636 removes it

rnk added a comment.May 4 2017, 9:41 AM
In D26586#746128, @rnk wrote:

I feel like we need to step back and ask why we are using the variable size information provided by the frontend at all. I don't think MSVC uses it. We probably only needed it because our intel asm matcher couldn't cope with ambiguity before and it was getting the wrong sizes.

I'm going to look into removing the frontend-directed AOK_SizeDirective rewrite altogether.

I looked into this more and commented on the new patch D32636