[PATCH] D37177: [X86] Don't disable slow INC/DEC if optimizing for size

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Aug 27 07:44:01 PDT 2017


spatel added a comment.

In https://reviews.llvm.org/D37177#853325, @craig.topper wrote:

> I'd also like to see less feature flags. Particularly the ones that encode the CPU name into a flag.


Yes, those are extra wrong. :)

> Is there anything in the CPU scheduler model that captures INC/DEC being slow. I think its only "slow" because it doesn't update the carry flag and creates false dependencies later.

There's nothing in there currently that I can see. We could transfer fake feature bits into the SchedMachineModel (a rename of that object might be due at that point) or something off to the side of it?

> I also think it should be disabled on earlier CPUs than Haswell. I don't think anything change in microarchitecture at Haswell that made it different. gcc disables INC/DEC at least back to "core2".

Yes, I doubt we'll ever get a complete 1-to-1 mapping from uarch characteristic to the output code we want to see, so we'll end up fudging it. But at least if it's at the MI layer, we'll have a more principled approach about when it gets activated?

Side note specifically about this one: the goal of -Os (optsize) is fuzzy. Where to draw the line between size and perf is never clear to me. I thought -Oz was defined more concretely (reduce size no matter what it does to perf), but even that is not clear based on the current text ("Like -Os but reduces code size further").  So I don't object to this patch if it makes llvm behavior less suprising vs. gcc (or there's some measurable win somewhere?), but if we can move this case to MI just as easily and/or create some infrastructure to get all of the fake features moved over, I think that's preferable.


https://reviews.llvm.org/D37177





More information about the llvm-commits mailing list