similar to: [LLVMdev] Variable name from metadata

Closing this, found below links to get variable name.   http://groups.google.com/group/llvm-dev/browse_thread/thread/1a239f0d24db2b5c   http://markmail.org/message/fj5qg44vyjsdde7k#query:+page:1+mid:5zhmyncisenomcga+state:results           I could do following, to get the required information.                 const CallInst *CI = dyn_cast<CallInst>(Insn);                 int numoperands =

You can call addIncoming(). /// addIncoming - Add an incoming value to the end of the PHI list /// void addIncoming(Value *V, BasicBlock *BB) { assert(V && "PHI node got a null value!"); assert(BB && "PHI node got a null basic block!"); assert(getType() == V->getType() && "All operands to PHI node must be the same

On 9 Nov 2013, at 16:35, William Moses <moses.williamsteven at gmail.com> wrote: > Is it possible to create something which has the same effect of a variable-length phi node in the C++ api. Specifically, create a phi-node where the number of incoming values is not known at the time of its creation. The PHI node preallocates its storage, so no. > If there is no such way of creating a

All, Is it possible to create something which has the same effect of a variable-length phi node in the C++ api. Specifically, create a phi-node where the number of incoming values is not known at the time of its creation. If there is no such way of creating a phinode like that, would it be possible to create a dummy instruction and perform a replaceAllUsesWith? If so, what should the dummy

Hi, If I have an instance of DISubprogram, can I get the debug info of local variables of the function, including parameters? I tried to use the getVariables() function defined in DISubprogram, but it seemed to return an empty DIArray node when I ran my pass alone using opt. Do I need to enable any other analysis passes in order to populate the data? My related snippet of code is like the

On 2017-01-20 14:31, Hal Finkel wrote: > > On 01/20/2017 06:11 AM, Jonas Paulsson via llvm-dev wrote: >> Hi, >> >> I wonder why getScalarizationOverhead() does not take into account >> the number of operands of the instruction? This should influence the >> number of extracts needed, so instead of >> >> Scalarization cost = NumEls * (insert +

I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM

Hi, I wonder why getScalarizationOverhead() does not take into account the number of operands of the instruction? This should influence the number of extracts needed, so instead of Scalarization cost = NumEls * (insert + extract) it would be better to do Scalarization cost = NumEls * (insert + (extract * numOperands)) / Jonas

Hi folk, In the Source Level Debugging document, llvm.dbg.declare takes two paramters. "The first argument is the alloca for the variable, cast to a {}*. The second argument is the llvm.dbg.variable containing the description of the variable." The second parameter corresponds to DIVariable, what is the corresponding LLVM class of the first parameter? I want to find which

I also want a way to add target specific flag to a SDNode (which should be transferred to MachineInstr). For example, on x86 lots of opcodes have *lock* variants. Right now, these are separate instructions. I'd prefer to make it into a target specific flag that can be toggled by some sort of post-isel action routine. One way to handle this might be to expand the use of SubclassData.

Right now the MemSDNode keeps a volatile bit in the SubclassData to mark volatile memory operations. We have some changes we'd like to push back that adds a NonTemporal flag to MemSDNode to mark instructions where movnt (on x86) and other goodness can happen (we'll also add the TableGen patterns to properly select movnt). In our tree we simply added another flag to the MemSDNode

On Thu, Jul 15, 2010 at 1:19 PM, Arvind Sudarsanam <arvind.sudarsanam at aggiemail.usu.edu> wrote: > Hi Devang, > > Thanks for your reply. You mentioned > " First parameter is the compiler generated temp. and 3rd parameter > provides info about the variable, including its name 'u'." > > I did manage to get this far. But, I am finding it difficult to

Hello, This example input crashes if you run it through llc on x86. [begin example] ; ModuleID = 'test' %struct_2 = type { [90000 x %struct_1] } %struct_1 = type { i8 } define void @testFcn(%struct_2 %in1) { testFcn_entry: %in1_ = alloca %struct_2 store %struct_2 %in1, %struct_2* %in1_, align 8 %localStruct_ = alloca %struct_2 store %struct_2 %in1, %struct_2* %localStruct_,

Hi Devang, Thanks for your reply. You mentioned " First parameter is the compiler generated temp. and 3rd parameter provides info about the variable, including its name 'u'." I did manage to get this far. But, I am finding it difficult to access this info using LLVM APIs. The third parameter is of type "metadata". So I was able to access it by casting it to MDNode.

Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified

Hi Folks, I ran into this assertion failure while compiling a function with a large number of arguments: https://llvm.org/bugs/show_bug.cgi?id=21609 I have coded up the fix as per David's suggestion (added a new header field for DIVariable to separate out ArgNo & LineNo). The proposed diff is attached to the bug. However, there are around 175 testcases across clang & llvm that need

> On 2015-Jan-19, at 12:38, Frédéric Riss <friss at apple.com> wrote: > > >> On Jan 19, 2015, at 12:04 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote: >> >> >> I forgot to mention this in my initial email. >> >> The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c >> The date on the

On Sunday 02 August 2009 20:57, Evan Cheng wrote: > I also want a way to add target specific flag to a SDNode (which > should be transferred to MachineInstr). For example, on x86 lots of > opcodes have *lock* variants. Right now, these are separate > instructions. I'd prefer to make it into a target specific flag that > can be toggled by some sort of post-isel action routine.

On Sat, Nov 2, 2013 at 4:17 PM, lu zhao <luzhao at cs.utah.edu> wrote: > Hi, > > If I have an instance of DISubprogram, can I get the debug info of local > variables of the function, including parameters? > > I tried to use the getVariables() function defined in DISubprogram, but it > seemed to return an empty DIArray node when I ran my pass alone using opt. > Do I

When trying to display and do anything with a variable of type IntrinsicInst, gdb thinks that it's an incomplete type and kind find any member functions or even display the class. (gdb) list 1337 1332 1333 // Finish off the call including any return values. 1334 return finishCall(CLI, RetVT, NumBytes); 1335 } 1336 1337 bool MipsFastISel::fastLowerIntrinsicCall(const