Rename hasCMPXCHG16B() to useCMPXCHG16B() to make it less like other
feature functions.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/X86/X86InstrInfo.td | ||
---|---|---|
2238 | I used hasCX16 here instead of useCMPXCHG16B since we have to use In64BitMode explicitly any way for the assembler. |
llvm/lib/Target/X86/X86Subtarget.h | ||
---|---|---|
722–724 | I have a little concern about the name:
I'm afraid adding useCMPXCHG16B would make hasCX16 useless. |
llvm/lib/Target/X86/X86Subtarget.h | ||
---|---|---|
722–724 | I should probably use hasCX16() in useCMPXCHG16B() instead of HasCX16. That would match with is64Bit(). useCMPXCHG16B name is kind of like the existing UseSSE and UseAVX predicates. Would canUseCMPXCHG16B or canUseCX16 be better? Ultimately my goal is to get rid of the concept of a non-trivial feature from the other patch. The Subtarget interface is bad right now, and it’s mostly that way because naming things is hard. I’m a little tempted to remove useCMPXCHG16B and just put the is64Bit check at the callers. |
llvm/lib/Target/X86/X86Subtarget.h | ||
---|---|---|
722–724 |
Okay, then UseCX16 makes sense for me.
This method can not get rid of non-trivial feature like useAA, which has an virtual interface. I think non-trivial feature brings the flexibility, which gives the developer chance to hack the code quickly and see the difference, so it's important.
This brings burdon to the user, which is worrying. |
I used hasCX16 here instead of useCMPXCHG16B since we have to use In64BitMode explicitly any way for the assembler.