[llvm-dev] [FPEnv] FNEG instruction

[Sanjay Patel via llvm-dev]

On Tue, Sep 25, 2018 at 7:47 PM Cameron McInally <cameron.mcinally at nyu.edu>
wrote:

>
> This is the first time I'm looking at foldShuffledBinop(...), so maybe a
> naive question, but why not do similar shuffle canonicalizations on unary
> (or ternary) operations? That may be a better fix in the long run.
>

AFAIK, all of the math/logic folding that we do currently is on binary
operators because all of the instructions have that form:
http://llvm.org/docs/LangRef.html#instruction-reference

As discussed, we fake the unary neg/not/fneg as binops. Excluding
control-flow, the only unary instructions are casts, and I don't see any
ternary or higher math ops other than intrinsics.

I don't think there's any incentive to change the integer neg/not, so that
makes fneg the oddball (and maybe that's why it was implemented as it is?).



> But glancing at Reassociate.cpp is scarier. It does a lot of stuff like
>> this:
>>     if (BinaryOperator::isNeg(TheOp) || BinaryOperator::isFNeg(TheOp))
>>       X = BinaryOperator::getNegArgument(TheOp);
>>
>> I think that's going to fail without a (terrible) hack to treat the
>> proposed fneg as a binop. So that's probably a preliminary requirement:
>> find all uses of BinaryOperator::isFNeg() and update them to use m_FNeg().
>> That should be done ahead of the IR change to limit damage. I don't know if
>> that's enough as-is, but we know that code will break without an update.
>>
>
> Ah, yeah. So this worries me too. Both floating point and integer negate
> are syntactic sugar for (-0-x). I did not know that. It would be ugly to
> unwrap floating point negate without doing the same for integer negate. :/
>

Agreed - regardless of the outcome of fneg, it's probably worth replacing
all of those fake binop API uses just to make the code uniform.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/71e89301/attachment.html>