search for: targetselectiondaginfo

I am not seeing this happening, at least not for unreachables that follow calls to 'noreturn' functions. On Apr 14, 2014, at 3:48 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello > > x86 backend emits ud2 instruction in this case > > On Mon, Apr 14, 2014 at 1:46 PM, Vadim Chugunov <vadimcn at gmail.com> wrote: >> Hi, >> Is it

...hing from include/llvm/CodeGen. The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering, TargetLoweringObjectFile, TargetMachine, TargetOptions, TargetRegisterInfo and TargetSubtargetInfo. The .h files that moved are the matching headers for the .cpp files plus TargetInstrInfo, TargetSelectionDAGInfo and TargetLowering. Please review! More generally, I suggest reviewing the idea of moving everything rather than looking at the patch itself. The patch is lots of changing Target/X to CodeGen/X, nothing exciting. Nick -------------- next part -------------- A non-text attachment was scrubbed......

...from include/llvm/CodeGen. > > The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering, TargetLoweringObjectFile, TargetMachine, TargetOptions, TargetRegisterInfo and TargetSubtargetInfo. The .h files that moved are the matching headers for the .cpp files plus TargetInstrInfo, TargetSelectionDAGInfo and TargetLowering. > > Please review! More generally, I suggest reviewing the idea of moving everything rather than looking at the patch itself. The patch is lots of changing Target/X to CodeGen/X, nothing exciting. > > Nick > <target-no-codegen-llvm-1.patch><target-no-co...

We've had a circular dependency in LLVM for a while, and while we've been fortunate that we could ignore it by implementing functions in header files, a recent innocent change caused a cyclic dependency between Target and CodeGen just because of inlining that happens in GCC. I'm proposing to fix this by moving code from Target to CodeGen If I understand correctly, lib/CodeGen is

...clude/llvm/CodeGen. >> >> The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering, TargetLoweringObjectFile, TargetMachine, TargetOptions, TargetRegisterInfo and TargetSubtargetInfo. The .h files that moved are the matching headers for the .cpp files plus TargetInstrInfo, TargetSelectionDAGInfo and TargetLowering. >> >> Please review! More generally, I suggest reviewing the idea of moving everything rather than looking at the patch itself. The patch is lots of changing Target/X to CodeGen/X, nothing exciting. >> >> Nick >> <target-no-codegen-llvm-1.patch&g...

...gt; SelectionDAGBuilder::visitUnreachable() is basically a no-op. So I don't > see how it could have generated anything... > > What would be the right way to go about adding this functionality? > Right now I am thinking to add 'EmitTargetCodeForUnreachable()' method to > TargetSelectionDAGInfo class, so that targets can emit code for > 'unreachable', if they need that. Does that sound right? > Personally I'm in favor, but others may disagree. Right now clang inserts calls to llvm.trap(), and that's how we get ud2's when falling off the end of a function with...

.../Target/TargetRegistry.h -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetSchedule.td -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetSelect.h -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetSelectionDAG.td -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetSelectionDAGInfo.h -- Installing: /usr/local/llvm-2.8/include/llvm/Target/TargetSubtarget.h -- Installing: /usr/local/llvm-2.8/include/llvm/Transforms -- Installing: /usr/local/llvm-2.8/include/llvm/Transforms/IPO -- Installing: /usr/local/llvm-2.8/include/llvm/Transforms/IPO/InlinerPass.h -- Installing: /usr/local...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel

...ase+Asserts build llvm[2]: Compiling ScopedNoAliasAA.cpp for Release+Asserts build llvm[2]: Compiling SparsePropagation.cpp for Release+Asserts build llvm[3]: Compiling IndVarSimplify.cpp for Release+Asserts build llvm[2]: Compiling TargetLibraryInfo.cpp for Release+Asserts build llvm[3]: Compiling TargetSelectionDAGInfo.cpp for Release+Asserts build llvm[3]: Building Release+Asserts Archive Library libLLVMSelectionDAG.a make[3]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/CodeGen/SelectionDAG' make[3]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/CodeGen/AsmPrinter' llvm[2]: C...