This is an archive of the discontinued LLVM Phabricator instance.

[X86] Make `prefetchit{0/1}` emit an assembler warning if the operand is not rip-rel
ClosedPublic

Authored by goldstein.w.n on Jan 27 2023, 7:40 PM.

Details

Summary

Without a rip-rel operand, prefetchit{0/1} is a nop. This is a
reasonable mistake for someone to make and is almost certainly not
what they are after.

This matches the same warning in gas.

Diff Detail

Event Timeline

goldstein.w.n created this revision.Jan 27 2023, 7:40 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 27 2023, 7:40 PM
goldstein.w.n requested review of this revision.Jan 27 2023, 7:40 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 27 2023, 7:40 PM
pengfei added inline comments.Jan 27 2023, 7:51 PM
llvm/test/CodeGen/X86/prefetchi-warning.ll
1 ↗(On Diff #492969)

This seems miss a half use case. User may use gas rather than native assembler. Maybe move it to early pass? X86InstrInfo::verifyInstruction looks like an ideal place, but it is just for error check.

goldstein.w.n added inline comments.Jan 27 2023, 7:59 PM
llvm/test/CodeGen/X86/prefetchi-warning.ll
1 ↗(On Diff #492969)

This seems miss a half use case. User may use gas rather than native assembler. Maybe move it to early pass? X86InstrInfo::verifyInstruction looks like an ideal place, but it is just for error check.

Or pass files assembler by GCC/hand-written to llvm-as...
Imo it makes more sense in gas + llvm-as than earlier.

Move tests to MC.
Make warning match verbatim with gas

goldstein.w.n added inline comments.Jan 28 2023, 9:54 AM
llvm/test/CodeGen/X86/prefetchi-warning.ll
1 ↗(On Diff #492969)

This seems miss a half use case. User may use gas rather than native assembler. Maybe move it to early pass? X86InstrInfo::verifyInstruction looks like an ideal place, but it is just for error check.

So the warning exists in GAS at the moment, since these commits:

commit ef07be453e0edf2f43034fcbc0581f61e630993e
Author: Cui, Lili <lili.cui@intel.com>
Date:   Mon Oct 31 21:07:17 2022 +0800

    Support Intel PREFETCHI

commit f2462532e24ebfc137598d73ee6541948121f040
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Mon Oct 31 09:01:15 2022 -0700

    x86: Silence GCC 12 warning on tc-i386.c

New warning matches verbatim with GAS.

goldstein.w.n edited the summary of this revision. (Show Details)Jan 28 2023, 9:55 AM

Fix commit msg

pengfei accepted this revision.Jan 28 2023, 10:56 PM

LGTM.

This revision is now accepted and ready to land.Jan 28 2023, 10:56 PM

Why not do this in X86AsmParser::validateInstruction?

goldstein.w.n added a comment.EditedJan 28 2023, 11:30 PM

Why not do this in X86AsmParser::validateInstruction?

AFAICT it only throws compilation errors.

Why not do this in X86AsmParser::validateInstruction?

AFAICT it only throws compilation errors.

I believe the uses of Warning in validateInstruction actually return false so they don't stop the parsing.

Why not do this in X86AsmParser::validateInstruction?

AFAICT it only throws compilation errors.

I believe the uses of Warning in validateInstruction actually return false so they don't stop the parsing.

Oh, I'm sorry I misread your earlier comment and thought you where referring to X86InstrInfo::verifyInstruction.

Yeah X86AsmParser::validateInstruction seems to make sense, will give it a shot for V3.

Use validateInstruction for validating prefetchit0 + make tests a bit better

Why not do this in X86AsmParser::validateInstruction?

Done.

pengfei added inline comments.Jan 29 2023, 12:45 AM
llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
3927–3928

How about Inst.getOperand(X86::AddrBaseReg)?

goldstein.w.n marked an inline comment as done.Jan 29 2023, 1:27 PM

Use X86::AddrBaseReg instead of looping