This is an archive of the discontinued LLVM Phabricator instance.

Implement MS _rot intrinsics
ClosedPublic

Authored by agutowski on Sep 7 2016, 1:03 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

agutowski updated this revision to Diff 70584.Sep 7 2016, 1:03 PM
agutowski retitled this revision from to Implement MS _rot intrinsics.
agutowski updated this object.
agutowski added reviewers: rnk, thakis, Prazek, compnerd.
agutowski added a subscriber: cfe-commits.
rnk added inline comments.Sep 7 2016, 1:49 PM
lib/CodeGen/CGBuiltin.cpp
740 ↗(On Diff #70584)

I don't think this is correct when rotating by zero. That will cause us to shift right by ArgTypeSize, which will result in an undefined value: http://llvm.org/docs/LangRef.html#lshr-instruction

I think we need to generate a select or conditional branch as in the original code.

test/CodeGen/ms-intrinsics-rotations.c
138 ↗(On Diff #70584)

Nice, testing both LP64 and LLP64. :)

rnk edited edge metadata.Sep 7 2016, 1:53 PM

You should locally verify that this generates the correct assembly when optimizations are enabled, and if it doesn't, try to make the input look more like llvm/test/CodeGen/X86/rotate.ll

test/CodeGen/ms-intrinsics-rotations.c
2 ↗(On Diff #70584)

Can we run without -Oz? The test should still pass.

agutowski updated this revision to Diff 70614.Sep 7 2016, 4:14 PM
agutowski edited edge metadata.

Fix undefined value problem when rotating by zero bits
Change tests to work without -Oz flag
Fix types of arguments in tests

agutowski marked 2 inline comments as done.EditedSep 7 2016, 4:29 PM
In D24311#536333, @rnk wrote:

You should locally verify that this generates the correct assembly when optimizations are enabled, and if it doesn't, try to make the input look more like llvm/test/CodeGen/X86/rotate.ll

Yeah, I checked that it's optimized to ROL/ROR instruction - now, after looking closer, I can see that it's optimized for all functions except for the ones operating on 16-bit integers. Could that be a calculated decision, or should I try to make it generate ROL/ROR whenever it can?

Edit: I tried to make the code as similar to the one from rotate.ll as possible, and it's still not optimized to ROL/ROR for 16-bit integers, so I guess it should stay that way.

lib/CodeGen/CGBuiltin.cpp
740 ↗(On Diff #70614)

Ah, I am sure I saw that bug, but apparently I forgot about it, as on my machine it returned correct values. Thanks!

In D24311#536333, @rnk wrote:

You should locally verify that this generates the correct assembly when optimizations are enabled, and if it doesn't, try to make the input look more like llvm/test/CodeGen/X86/rotate.ll

Yeah, I checked that it's optimized to ROL/ROR instruction - now, after looking closer, I can see that it's optimized for all functions except for the ones operating on 16-bit integers. Could that be a calculated decision, or should I try to make it generate ROL/ROR whenever it can?

Edit: I tried to make the code as similar to the one from rotate.ll as possible, and it's still not optimized to ROL/ROR for 16-bit integers, so I guess it should stay that way.

I wouldn't worry about this too much... It is up to the backend to do the right thing.

agutowski updated this revision to Diff 70646.Sep 7 2016, 9:04 PM
agutowski marked an inline comment as done.

Add evaluating values for constant arguments

majnemer added inline comments.Sep 7 2016, 9:20 PM
lib/AST/ExprConstant.cpp
7024–7050 ↗(On Diff #70646)

Any reason why we need this?

Given:

#include <intrin.h>

constexpr int x = _rotl8(1, 2);

MSVC 2015 reports:

error C2131: expression did not evaluate to a constant
agutowski added inline comments.Sep 8 2016, 11:26 AM
lib/AST/ExprConstant.cpp
7024–7050 ↗(On Diff #70646)

Hm, I don't know. Is there any reason why we shouldn't do this? I mean, I just had the feeling that if we can evaluate something during compilation time, we should to it.

majnemer added inline comments.Sep 8 2016, 11:29 AM
lib/AST/ExprConstant.cpp
7024–7050 ↗(On Diff #70646)

The best reason I can think of is that it allows people to use a Microsoft-specific intrinsic in ways which won't compile with Microsoft's compiler.

rnk added inline comments.Sep 8 2016, 1:51 PM
lib/AST/ExprConstant.cpp
7024–7050 ↗(On Diff #70646)

Yeah, I agree, we should drop the constexpr part of this. The use case for these intrinsics is really to get at the x86 instructions.

agutowski updated this revision to Diff 70747.Sep 8 2016, 1:56 PM

Remove evaluating values for constant arguments

agutowski marked 4 inline comments as done.Sep 8 2016, 1:58 PM
rnk accepted this revision.Sep 8 2016, 2:29 PM
rnk edited edge metadata.

lgtm

This revision is now accepted and ready to land.Sep 8 2016, 2:29 PM
This revision was automatically updated to reflect the committed changes.