[llvm-dev] DAGLegalizer Issue
Friedman, Eli via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 17 11:34:18 PST 2017
On 1/17/2017 5:04 AM, pbrunet via llvm-dev wrote:
> As I try to compile some generated llvm IR, I have an issue with the
> shuffle instruction on FloatingPoint reaching an assert in the DAGLegalizer.
> I try to produce a patch to fix it and I wonder what is the best way to
> handle it.
> Now the problem:
> There is a shuffle transformation like:
> ; fold: (shuffle (bitcast (BINOP A, B)), Undef, <Mask>)
> ; (shuffle (BINOP (bitcast A), (bitcast B)), Undef, <Mask>)
> For X86 with BINOP in (FADD, FMUL, FSUB, ADD, MUL, SUB).
This is combineShuffle in X86ISelLowering.cpp?
> It seems OK and I don't want to change that but I have a case where
> bitcast is done from float to int. In this case, we can't perform this
> as FADD can't be apply on integers.
Actually, you can still perform the transformation; for ADD, you just
need to compute an equivalent integer type to use for the binop, then
insert an extra bitcast afterwards.
On a side-note, I'm pretty sure the transform isn't legal for
floating-point vectors; you can get away with extending an integer by
putting garbage into the high bits, but you can't extend a
floating-point value that way
> I could have fix it here and say : FADD, FMUL, FSUB can be switch with
> float bitcast only and ADD/MUL/SUB with intergers bitcast only. But few
> lines above there is an if with:
> TLI.isOperationLegal(Opcode, VT).
> It means that Opcode == FADD and VT type == Integers return True (so is
> Legal) and it doesn't looks correct to me.
This is arguably wrong, but it doesn't matter because we shouldn't be
trying to FADD integers anyway.
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
More information about the llvm-dev