[PATCH] D48832: [ARM] ARMCodeGenPrepare backend pass
Eli Friedman via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 3 12:30:08 PDT 2018
efriedma added a comment.
> what was the extra instruction that you're generating in your example
The movw. We should generate ldrsh+cmn, like we do for "*x < -3".
================
Comment at: lib/Target/ARM/ARMCodeGenPrepare.cpp:280
+ case Instruction::Add:
+ return TypeSize == 16 ? Intrinsic::arm_uadd16 :
+ Intrinsic::arm_uadd8;
----------------
samparker wrote:
> efriedma wrote:
> > Is it safe to generate calls to uadd? It writes to the GE bits, and user code could potentially read them.
> Currently intrinsics are the only way to read and write the GE flag, but no it doesn't mean its safe. Is there a way to query the function/module for the intrinsics used? If there's no sel intrinsic being used, we are okay to use these instructions. Either way, I'll change the default to disable the generation of these instructions.
You can call use_empty() on any particular intrinsic, but that probably isn't what you want; either we assume GE is clobbered across function calls (in which case we only want to check the current function), or we assume it's preserved across function calls (in which case checking the current module isn't sufficient).
================
Comment at: lib/Target/ARM/ARMCodeGenPrepare.cpp:441
+bool ARMCodeGenPrepare::isNarrowInstSupported(Instruction *I) {
+ if (!ST->hasDSP() || DisableDSP || !isSupportedType(I))
+ return false;
----------------
samparker wrote:
> efriedma wrote:
> > Do we need to check we have Thumb2, if we're in Thumb mode?
> I thought DSP should cover it since they're only available in Thumb2, but an explicit check wouldn't hurt.
"hasDSP()" is essentially just the "dsp" subtarget feature, which is whether the target CPU supports DSP instructions in either ARM or Thumb mode. This makes perfect sense from the perspective of subtarget features (since whether a function is in Thumb mode is independent of the target CPU), but it's a little confusing in this context.
https://reviews.llvm.org/D48832
More information about the llvm-commits
mailing list