similar to: [LLVMdev] Possible Typo in SelectionDAGLowering::visitShuffleVector

I ran into some odd code being generated today and I came across something that doesn't look quite right. In SelectionDAGBuilder::visitShuffleVector there's some code to see if we can convert the shuffle to an EXTRACT_SUBVECTOR. After computing min/max values of the mask for each operand, there's a look that looks at the ranges and determines whether an EXTRACT_SUBVECTOR can be used:

Please tell me whether the following implementation is correct..... My target supports 64 bit mask means immediate(0-2^63) I have implemented it but i dont know whether its correct or not. Please see the changes below that i have made in x86isellowering.cpp static SDValue lower2048BitVectorShuffle(const SDLoc &DL, ArrayRef<int> Mask, MVT VT,

On Fri, Feb 7, 2020 at 12:29 PM Nuno Lopes <nunoplopes at sapo.pt> wrote: > > It's not correct (output of Alive2): > > define half @fn(half %a) { > %b = fadd half %a, undef > ret half %b > } > => > define half @fn(half %a) { > ret half undef > } > Transformation doesn't verify! > ERROR: Value mismatch > > Example: > half %a

So if I create a value with a DAG.getUndef(myVT); call during instruction legalization, how can I access that value as input in another BB/DAG (also during instruction legalization) without worrying about live-ins and/or phi nodes? Can I create a single virtual register and build both a CopyToReg and a CopyFromReg node with it? I assumed that would break SSA. Perhaps I should have said that what

So if I first create the value in an entry BB and then build a CopyToReg but then I have to read it in a BB that loops back to itself, with it's own CopyToReg at the end, then I have two CopyToReg nodes for the same value. In this case, I need to create 3 virt regs, 1 for each CopyToReg and a third for the CopyFromReg in the beginning of the loop BB, right? And then I need to build a PHI

Hello, While I was trying to cross-compile Linux OMAP kernel with llvm, I have the following error message. CC arch/arm/kernel/traps.o cc1: /home/wonjeon/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:5388: void llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallSite): Assertion `(OpInfo.ConstraintType == TargetLowering::C_RegisterClass || OpInfo.ConstraintType ==

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

Hi everybody, I just updated to the latest svn trunk version, but now the code does not compile anymore. It trows an error in "f:\dev\llvm\lib\system\Win32/DynamicLibrary.inc(159) : error C2228: left of '.find' must have class/struct/union". Below you can find the small patch which makes the compiler happy again :-) Sincerely yours Marius Wachtler

On Jul 8, 2009, at 11:16 AM, Won J Jeon wrote: > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I > have the following error message. > > CC arch/arm/kernel/traps.o > cc1: /home/wonjeon/llvm/lib/CodeGen/SelectionDAG/ > SelectionDAGBuild.cpp:5388: void > llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallSite): >

Bug #4521 has been filed. traps.c has been also attached. Thanks, Won On Wed, Jul 8, 2009 at 1:38 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 8, 2009, at 11:16 AM, Won J Jeon wrote: > > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I have the > following error message. > > CC arch/arm/kernel/traps.o >

On Jan 29, 2009, at 10:35 AM, Marius Wachtler wrote: > Hi everybody, > > I just updated to the latest svn trunk version, but now the code > does not compile anymore. > It trows an error in "f:\dev\llvm\lib\system\Win32/ > DynamicLibrary.inc(159) : error C2228: left of '.find' must have > class/struct/union". Oops, sorry about that, fixed, please

Hello I think I found a bug in the x86 instruction definition file, while trying out the disassembler. It looks like the "ADD32rr_alt" instruction should have GR32 operands, not GR16. Attached you can find a patch, which should fix the problem. But even with the change I can not decode e.g. "0x03 0xC1" (should be "addl %ecx, %eax") only if I remove the

Thanks for the bug report. The attached file isn't helpful for reproducing the problem. I don't have all the header files that are included, so I can't just try to run it through my version of llvm-gcc and see what happens. At a minimum, please attach the preprocessed source file along with the complete llvm-gcc command line that you used to compile it. That would

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

Hello The current svn revision fails to compile on windows using Visual Studio 2008. I'm getting: 3>f:\dev\llvm\lib\codegen\asmprinter\dwarfwriter.cpp(1167) : error C4716: 'llvm::DbgScope::getLine' : must return a value 3>f:\dev\llvm\lib\codegen\asmprinter\dwarfwriter.cpp(1168) : error C4716: 'llvm::DbgScope::getColumn' : must return a value

Hello If I optimize (opt -std-compile-opts ) the following .ll ; ModuleID = 'call0.ll' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i386-mingw32" define i32 @t(i32 %a) nounwind { entry: %0 = tail call i32 inttoptr (i32 0 to i32 (i32)*)(i32 %a) nounwind

Hello When I compile LLVM trunk with Visual Studio 2008 and cmake, the build is failing because a new file is not yet added to the build system. Attached you can find a patch which fixes the problem for me. Marius Wachtler Index: lib/Transforms/Scalar/CMakeLists.txt =================================================================== --- lib/Transforms/Scalar/CMakeLists.txt (revision 85194)

Hello Visual Studio is complaining about the mix of struct and class. 2>C:\dev\llvm\include\llvm/ADT/ValueMap.h(202) : warning C4099: 'llvm::DenseMapInfo<llvm::ValueMapCallbackVH<KeyT,ValueT,Config,ValueInfoT>>' : type name first seen using 'struct' now seen using 'class' 2> C:\dev\llvm\include\llvm/ADT/ValueMap.h(251) : see reference to class

> Dale Johannesen wrote: >> Marius Wachtler wrote: >> ... >> The call to address 0 gets removed. >> >> define i32 @t(i32 %a) noreturn nounwind readnone { >> entry: >> unreachable >> } >> >> How can I prevent that the call is removed, without making the >> function addr volatile? >> Does anyone know which optimization

I wish to assure you that I have not forgotten this task, nor failed to start on it, but I cannot give even a rough estimate on when it will be completed. It occurs to me that all declarations of a function pointer, and all bitcasts to a function pointer, could possibly refer to a function whose signature must be altered by this fix. Is the function signature relevant to the SelectionDAG