similar to: [LLVMdev] Valid debug information being deleted by DAGCombiner

Found another bitcode file where a debug symbol is being dropped. In the attached bitcode file, the variable gid is not in the debug output. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Thursday, April 14, 2011 5:31 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Valid debug information being deleted by DAGCombiner I am working

On 4/14/11 8:22 PM, Villmow, Micah wrote: > > Found another bitcode file where a debug symbol is being dropped. > > In the attached bitcode file, the variable gid is not in the debug output. > Dumb question: Have you looked to see if mem2reg is destroying (or not maintaining) the debug information of interest (or put another way, was the variable gid promoted to an LLVM register

John/Richard, I think I have found the problem to why the debug information is getting destroyed. The problem is in SelectionDAG and how it interacts with the SDDbgValue nodes and custom SDNodes. When the dbg_value intrinsic is encountered, it adds the debug value to a specific SD Node in SelectionDAGBuilder.cpp::visitIntrinsicCall(). In one of my cases, it is vector_extract_elt. During

John, Mem2reg actually modifies debug information in a way that at least suggests it's trying to maintain debugability. Specifically, it changes llvm.dbg.declare() calls (appropriate for variables that permanently reside in a single place) to llvm.dbg.value() calls (specifying that at this instant, this variable is in this register). In fact, the .bc after inlining and mem2reg

On Apr 15, 2011, at 2:21 PM, Villmow, Micah wrote: > John/Richard, > I think I have found the problem to why the debug information is getting destroyed. The problem is in SelectionDAG and how it interacts with the SDDbgValue nodes and custom SDNodes. > > When the dbg_value intrinsic is encountered, it adds the debug value to a specific SD Node in

Thanks Devang. Is there any plan on making this implicit in the node creation? Or instead of using DebugLoc in SelectionDAG, use SDDbgValue's instead, or embedding the SDDbgValue in the debug loc itself somehow? This seems like something that shouldn't have to be handled on a case by case basis in the backends. Your thoughts? Thanks, Micah From: Devang Patel [mailto:dpatel at

Hi, as you come to speak of it, i have implemented an OpenCL-Backend for LLVM as part of my bachelor thesis (and for GLSlang as well, see http://www.cdl.uni-saarland.de/publications/theses/moll_bsc.pdf ). However, the code is currently unreleased. But that could be arranged, if you are interested in using it. Regards, Simon Am Freitag, den 26.08.2011, 20:11 -0500 schrieb llvmdev-request at

On Thu, Dec 4, 2008 at 7:08 PM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 4, 2008, at 8:58 AM, Villmow, Micah wrote: > > What optimization pass promotes 32 bit math operations to 64 bit operations > so I can disable it? I have code that works fine with optimizations turned > off but fails with it turned on because of this stage. > > > Do you have a

On Mon, Oct 12, 2009 at 8:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Oct 12, 2009 at 6:15 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: >> I have a test case(attached as fc_long.ll) that when run through the >> optimizer produces 65bit integer math(fc_long-opt.ll). >> >> >> >> Now I understand that llvm can have any

Eli, I think I was able to get it working. Thanks for the help, does this look correct to you? void DAGTypeLegalizer::SplitVecRes_SIGN_EXTEND_INREG(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue LHSLo, LHSHi; GetSplitVector(N->getOperand(0), LHSLo, LHSHi); DebugLoc dl = N->getDebugLoc(); EVT LoVT, HiVT;

if (N0.getOpcode() == ISD::SETCC && (LegalOperations || (!LegalOperations && VT.isPow2VectorType()))) But the comment right after it is: // sext(setcc) -> sext_in_reg(vsetcc) for vectors. // Only do this before legalize for now. if (VT.isVector() && !LegalOperations) { So, these optimizations are never safe in the general case if we can't

Eli, Using the variables from the original IR, assuming tmp == tmp1 and assume the value is not nan ogt(tmp, tmp1) is !isnan(tmp) && !isnan(tmp1) && tmp > tmp1, or false ule(tmp, tmp1) is isnan(tmp) || isnan(tmp1) || tmp <= tmp1, or true So, this is invalid, or am I misunderstanding what ogt and ule stand for? Assuming this is valid, why convert comparison instructions

What does nsw nuw do? Micah -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dan Gohman Sent: Tuesday, October 13, 2009 10:06 AM To: Jeffrey Yasskin Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] 65bit integer math On Oct 12, 2009, at 9:42 PM, Jeffrey Yasskin wrote: > On Mon, Oct 12, 2009 at 8:22 PM, Eli Friedman

Ok, It doesn't work. The problem is LLVM then asserts later on in SelectionDAG:2642 because it is checking to see whether the second operand is an Integer, and if not it assumes it is floating point and asserts with the method Cannot *_EXTEND_INREG FP types. So, it seems that the root problem here is the 'MVT::Other' still hanging around. How do I convert this SDValue to an int vector

It is my understanding that all you need to do is specify let isTarget = 1 in your .td file and it will generate target specific intrinsics. This should allow you to keep the IntrinsicsPTX.td file in the same location. Micah From: Justin Holewinski [mailto:justin.holewinski at gmail.com] Sent: Monday, December 05, 2011 6:13 AM To: Alberto Magni Cc: Villmow, Micah; LLVM Developers Mailing List

We no longer have vsetcc, so the comment is wrong. The code looks incorrect. The fact that a vector is power-of-two does not guarantee anything about its legality. For example <128 x i64> would pass the condition in the code below, and die on most targets. From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Friday, July 27, 2012 22:33 To: Rotem, Nadav; Developers Mailing List

Sorry, accidently hit send hotkeys before finishing email. I am still trying to figure out why my comparison instructions are being modified and overall producing incorrect results. The IR produces correct results, but my backend does not and the only thing I can think of is that the IR is treating the Booleans as i1 and therefore either and'ing or xor'ing the results of my

instcombine doesn't seem to be doing it. From my testing it seems to only occur when I use -indvars after a long string of commands. For example: llvm-as < test_fc_27.ll | opt -preverify -domtree -verify -lowersetjmp -raiseallocs -simplifycfg -domtree -domfrontier -mem2reg -globalopt -globaldce -ipconstprop -deadargelim -instcombine -simplifycfg -ba siccg -prune-eh -inline

On Thu, Dec 10, 2009 at 12:46 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Eli, >  I have a simple SplitVecRes function that implements what you mentioned, splitting the LHS just as in BinaryOp, but passing through the RHS. The problem is that the second operand is MVT::Other, but when casted to an VTSDNode reveals that it is a vector length of the same size as the LHS

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, September 10, 2008 3:30 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg On Wed, Sep 10, 2008 at 2:35 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Generating the following LLVM IR: > > define