search for: selectiondags

Hi, Some random sample of VS warning: Lot of 64 bits conversions: AsmPrinter.cpp ..\..\lib\CodeGen\AsmPrinter.cpp(277) : warning C4244: 'initializing' : conversion from 'uint64_t' to 'unsigned int', possible loss of data ..\..\lib\CodeGen\AsmPrinter.cpp(614) : warning C4244: 'argument' : conversion from 'uint64_t' to 'int', possible loss of data

Hello, it looks like I do have infinite loop in llc on linux/armv7 platform somewhere in llvm::SmallVectorImpl. Two backtraces obtained with 10 seconds delay are: 0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd (this=0x7ee90b38, P=0x5c06988) at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:103 103 void setEnd(T *P) { this->EndX = P; }

As I’m sure many of you have noticed, I no longer have the time to be a proper code owner for SelectionDAG. In the interest of the project and to keep development running smoothly, I am resigning my code ownership. Justin Bogner has graciously volunteered to take it up. He has a strong history of LLVM contributions, a demonstrated commitment to good community development practices, and has

> > The other thing that might work, is having TargetMachine remember how > > the fast-isel option got set, and make OptLevelChanger do the right > > thing. But that seems like a hack to work around Mips not obeying the > > specified optimization level, honestly. > > I think we should do that as well. I don't think it's right that optnone > enables Fast

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

On Fri, Jun 24, 2011 at 9:12 AM, Karel Gardas <karel.gardas at centrum.cz> wrote: > Hello, > > it looks like I do have infinite loop in llc on linux/armv7 platform > somewhere in llvm::SmallVectorImpl. Two backtraces obtained with 10 > seconds delay are: > > 0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd > (this=0x7ee90b38, P=0x5c06988)

I'm still working on SSP support in LLVM. We have code that is in an IR pass StackProtector, SelectionDAG, FastISel, and some MachineFunction passes. Even in SelectiondDAG we have different code paths. I wonder if we can at least have only two code paths, one for SelectionDAG and the other for FastISel. IR pass may generate two forms of IR: 1) Almost pure IR, which contains only

Well, 'optnone' is already not identical to -O0, and given the nature of things, probably can't be; but I am persuaded that it's reasonable for it to honor the -fast-isel option as a debugging tactic. I'll take an AI to make this happen. Thanks, --paulr P.S. One nit, the "O0 + optnone" case should not have an asterisk, the FastISel flag is not manipulated if the opt

Hi, I've been experimenting with global isel over the last few weeks and it is such a vast improvement over the SelectionDAG for the AMDGPU target that I would really like to begin using it as soon as possible. Given the lack of a replacement for SelectionDAG's legalizer / combiner, and how much work this will be to implement, I think the fastest path to doing this would be to run some

Hi Anton & Duncan, When I try to compile on Darwin now, I get this: $ /Volumes/Gir/devel/llvm/llvm-gcc-4.0.obj/gcc/xgcc <options> -o eh_alloc.o Assertion failed: (false && "Couldn't find the register class"), function getPhysicalRegisterRegClass, file /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp, line 269.

Here is a series of patches replacing EVT with MVT at a number of places in TargetLowering. The last two patches are related cleanups in SelectionDAGBuilder. /Patrik Hägglund > git log --stat --reverse origin/master.. commit 8dabe3eb005360347eabb86a2e88c3b6e9098ed5 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 10:37:37 2012 +0100 Change

Dear LLVM, I'm trying to understand why the attached IR code works for x86_64 target and fails for nvptx64, because of unimplemented expand during the target lowering. Any ideas? Just change the target triple to x86_64-unknown-unknown, and the same IR code could we successfully codegen-ed for x86_64. Thanks, - Dima. dmikushin at dmikushin-desktop:~/Desktop$ gdb ~/sandbox/bin/llc GNU gdb

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

The diff is not only the && and || but also the leading !: diff --git a/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp b/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp index 58f029fbe9fc..7ee06fc153b2 100644 --- a/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp +++ b/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp @@ -659,7 +659,7 @@ void SelectionDAGISel::CodeGenAndEmitDAG() {

new warnings, I think lib/CodeGen/SelectionDAG/DAGCombiner.cpp: In member function ‘llvm::SDValue<unnamed>::DAGCombiner::FindBetterChain(llvm::SDNode*, llvm::SDValue)’: lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6006: warning: ‘SrcValueOffset’ may be used uninitialized in this function lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6006: note: ‘SrcValueOffset’ was declared here

Hello all, I am currently working with LLVM and make use of the debug output from llc. The SelectionDAG dumping features are especially interesting to me since I am looking for operation patterns that allow me to decide which custom instructions can be added to a processor in order to improve the performance. Providing a -view-dag-combine1-dags option (and its friends) to llc show the

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

On Apr 24, 2013, at 5:53 PM, Reed Kotler <rkotler at mips.com> wrote: > One question : > > "In the spirit of the (long-term) intent to migrate away from the > SelectionDAG framework" > > .. is this meant in general or just in respect to legalization? Everything. This includes all of the custom lowering code for all of the targets, all of dagcombine, and maybe

I actually need this feature quite badly in my untyped language compiler: since I support first-class functions, I've made the types of all functions a standard vararg (so I can box them). The implementation crashes when I try to read out the value of gc.result. Hints as to what might be wrong? Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> ---

On Wed, May 20, 2009 at 1:19 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > Per subject, this patch adding an additional pass to handle vector > operations; the idea is that this allows removing the code from > LegalizeDAG that handles illegal types, which should be a significant > simplification.  There are still some issues with this patch, but does > the approach