similar to: [LLVMdev] Fix wrong x86 inst encoding / problem with disassembler

Hi, The x86 (32-bit) disassembler can't disassemble any of the following: 0x2b 0xc9 0x8a 0xc8 0xdd 0x04 0x24 These are: subl %ecx, %ecx movb %al, %cl fldl (%esp) I've attached patches to bug#8873 which fix all these issues, but I'm not confident that I've fixed them the right way. The first two problems are caused by the instructions setting 'isCodeGenOnly =

Hello While building LLVM, the compiler (static analysis) is giving me a warning about "if (RangeUse[0] == 0 && RangeUse[0] == 0) {". Can somebody familar with the codebase look over it, maybe this should be "if (RangeUse[0] == 0 && RangeUse[1] == 0) {", otherwise sorry for the noise. Index: F:/dev/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp

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 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 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

On Oct 18, 2011, at 2:46 PM, Jakob Stoklund Olesen wrote: > > On Oct 18, 2011, at 2:33 PM, Sanjoy Das wrote: > >>> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. >> >> This is exactly what I was missing. Thanks a ton! :) > > We have three pseudo expansion passes: > > 1. ExpandISelPseudos.cpp - For instructions that may need to

0x0f 0x6f 0xc8 And 0x0f 0x7f 0xc1 Should both be movq % mm0, % mm1. (AT&T) However, llvm 3.4 at least does not recognise the second variant as being a valid instruction. We are currently compiling up latest src incase it has been fixed. If not, could someone take a look or recommend how to fix? Lee -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Oct 18, 2011, at 2:33 PM, Sanjoy Das wrote: >> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. > > This is exactly what I was missing. Thanks a ton! :) We have three pseudo expansion passes: 1. ExpandISelPseudos.cpp - For instructions that may need to create basic blocks, like CMOV and atomics. 2. ExpandPostRAPseudos.cpp - For instructions used to trick the

> But where is the flat set? Maybe I can debug and check what is going on. The MCInstrDesc are in a table in lib/Target/PowerPC/PPCGenInstrInfo.inc of your build directory. > Some additional information: > > MCInst opcode: 0x7cb > Decode Index: 0x1e I had assumed this would have dissembled to '// Inst #234 = BC' which does have the branch flag set, but I think that

On 4 October 2016 at 19:50, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > If there are no objections, I'd like to start working on this soon... > > For the AMDGPU target this implies that RC->getSize will no longer be > available in the MC layer. Another advantage of this work that hasn't been mentioned yet is it will reduce the number of uses

H all, I'm looking at generating PIC code for RISC-V in the context of Linux. Not sure if anyone is working on this already, any inputs are very welcome. I'm now looking at function calls which in the RISCV backend are represented via two pseudoinstructions RISCV::TAIL and RISCV::CALL. Currently those pseudos are lowered in MCCodeEmitter. They are expanded into AUIPC and JALR

Does anybody know is there is a way to print all the property values for a given def? For example I have a following instruction definition in the .td file let isReturn = 1, isTerminator = 1, hasDelaySlot=1, isBarrier = 1, isCodeGenOnly = 1, Inst = 0x44004800 in { def RET : InstBR<0x1, (outs), (ins), "l.jr\tr9", [(retflag)]>; } Ultimately

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

Hi Ulrich, Thank you for looking at this. Apologies again for taking unjustifiably long to get back to you. This is really good stuff and I very much want to see this go in. I like it enough I’m going to try to talk you into doing even more work on improving this code. ;) Fair warning up front: You’re digging into some pretty fundamental problems in how the assemblers and code generators like to

Hello. I come back to this thread. But I want to ask a slightly different question. Is there a way to have LLVM IR language intrinsics that are given at construction time a string that is written at assembly generation time as it is? (so, basically having placeholders of strings in LLVM that remain untouched until the end, including code generation time.) More exactly, I would

Hi Jim, > Thank you for looking at this. Apologies again for taking > unjustifiably long to get back to you. This is really good stuff and > I very much want to see this go in. I like it enough I’m going to > try to talk you into doing even more work on improving this code. ;) > > Fair warning up front: You’re digging into some pretty fundamental > problems in how the