This is an archive of the discontinued LLVM Phabricator instance.

Improve support for i386 and i486 CPUs.
AcceptedPublic

Authored by jyknight on Apr 5 2016, 12:18 PM.

Details

Reviewers
echristo
Summary

As far as "normal" instructions go, only a few are present in the 586
but not in the earlier processors: the 486 doesn't have CMPXCHG8B, and
386 is additionally missing BSWAP, CMPXCHG, and XADD.

Previously, llvm would emit these instructions even if you asked to
target a 386.

XADD and CMPXCHG are used only for atomics; we now ask AtomicExpandPass
to deal with expanding to libcalls on these CPUs, so it's trivial to
avoid emitting those.

BSWAP, then, is all that remains to be dealt with. It gets a custom
expansion, because the 3 ROR instructions is better than the default
expansion for bswap (which can't take advantage of the partial register
updating on x86.)

Depends on D18201

Diff Detail

Event Timeline

jyknight updated this revision to Diff 52723.Apr 5 2016, 12:18 PM
jyknight retitled this revision from to Improve support for i386 and i486 CPUs..
jyknight updated this object.
jyknight added a subscriber: llvm-commits.
ab added a subscriber: ab.Apr 5 2016, 2:03 PM

For BSWAP: would it work to do the custom lowering at ISel time instead of using a pseudo? I think it's possible to even write a pattern.

lib/Target/X86/X86.td
279

Should these features be on the remaining models? It'd probably be time to do ProcessorFeatures lists like SNB.

lib/Target/X86/X86InstrCompiler.td
1964

Make it obvious that it's a pseudo in the asmstring?

lib/Target/X86/X86InstrInfo.td
771

: alignment

test/CodeGen/X86/bswap.ll
25

Newline between the checks? And/or shorten CHECK386 -> I386?

RKSimon added a subscriber: RKSimon.Apr 5 2016, 2:27 PM
RKSimon added inline comments.
lib/Target/X86/X86ISelLowering.cpp
96

Subtarget.has486Insns() and Subtarget.has586Insns() are quiet vague about actual features, would it not be clearer to instead add Subtarget.hasCMPXCHG8() and Subtarget.hasCMPXCHG() that then uses Has586/Has486 internally?

Same for BSWAP (Subtarget.hasBSWAP()) below.

For BSWAP: would it work to do the custom lowering at ISel time instead of using a pseudo? I think it's possible to even write a pattern.

I don't know, is it? You'd need to be able to express the operation "rotate bottom 16 bits of this register by 8 bits, in place, leaving the upper 16 bits as they were". It's not a normal 16-bit operation, which would let you allocate 16-bit inputs/output virtual registers, because the contents of the upper bits are important.

lib/Target/X86/X86.td
279

I think it doesn't need to be, because I added it as implied by cmov, which everything else supports?

lib/Target/X86/X86ISelLowering.cpp
96

Sure, sounds fine.

ab added a comment.Apr 6 2016, 4:59 PM

For BSWAP: would it work to do the custom lowering at ISel time instead of using a pseudo? I think it's possible to even write a pattern.

I don't know, is it? You'd need to be able to express the operation "rotate bottom 16 bits of this register by 8 bits, in place, leaving the upper 16 bits as they were". It's not a normal 16-bit operation, which would let you allocate 16-bit inputs/output virtual registers, because the contents of the upper bits are important.

For the pattern: in my mind it was simple enough that you could duplicate the intermediate GR32 and let MachineCSE clean it up; but I tried writing it and it's actually pretty damn unwieldy:

def : Pat<(bswap GR32:$src),
    (INSERT_SUBREG
     (ROR32ri
      (INSERT_SUBREG (i32 GR32:$src),
       (ROR16ri (EXTRACT_SUBREG (i32 GR32:$src), sub_16bit), 8),
       sub_16bit),
      16),
     (ROR16ri
      (EXTRACT_SUBREG
       (ROR32ri
        (INSERT_SUBREG (i32 GR32:$src),
         (ROR16ri (EXTRACT_SUBREG (i32 GR32:$src), sub_16bit), 8),
         sub_16bit),
        16),
       sub_16bit),
      8),
     sub_16bit)
    >;

However, I think anything you can do in pseudo expansion, you could still do in ISelDAGToDAG, no?

Ideally you'd do it in SDAG, but there you're right, I don't think you can shoehorn it into the type system (not unless having machine nodes or something).

lib/Target/X86/X86.td
279

You're right, missed that, sorry!

echristo added inline comments.
lib/Target/X86/X86ISelLowering.cpp
96

Couple of comments here:

a) I definitely like the choice of better function naming for whether or not we have a particular cpu feature.
b) I'm not sure whether or not we want to conditionalize the 486/586 insns on sets of subtarget features or a broad ISA level feature. Unlike most of the later instructions added there's very little "subsetting" that we can do for this, that said, it forms a contrast with the rest of the port where we do have subtarget features for everything not baseline pentium.
c) That leads us to "hey, why not just set pentium as the baseline set of features and stop letting people select 386/486 as part of their compiles". Any thoughts here?

jyknight added inline comments.Apr 8 2016, 1:34 PM
lib/Target/X86/X86ISelLowering.cpp
96

My thoughts:

I have no personal use for < 586 processors. I have no idea if anyone in the world actually needs it. Quite possibly they don't. (I really have no idea).

However, it seems unfortunate that llvm/clang sort of pretend to support them, but don't actually. It would probably be better to return an error for -march=i[34]86, if we aren't going to support it. Although, doing that might break people's build setups, who decide to compile with -march=i386 for whatever reason, even though they don't actually mean to.

The code to support the processors is almost trivial, so there's really little reason not to just do it. (That's the only reason I even sent this patch -- because it touches upon the atomics stuff I'm working on, that there were FIXMEs about this support, and it looked fairly trivial to fix)

Added inline comment.

lib/Target/X86/X86ISelLowering.cpp
96

That leads us to "hey, why not just set pentium as the baseline set of features and stop letting people select 386/486 as part of their compiles". Any thoughts here?

Seems OK to me, with the exception that we definitely need to be able to specify Pentium ISA without x87 floating point. and that iseems covered under FeatureX87.

If this code is going to stay having Feature586Insns, and Feature486Insns, then where these are defined in X86.td ought to have a comment explaining exactly which instructions are covered in these features compared to "baseline" 386.

echristo accepted this revision.Apr 19 2016, 5:25 PM
echristo added a reviewer: echristo.

Sure, let's go ahead and just do this then (do fix up anything AB mentioned before committing).

Thanks!

-eric

This revision is now accepted and ready to land.Apr 19 2016, 5:25 PM
test/CodeGen/X86/bswap.ll