similar to: [LLVMdev] How to disable simplifying function parameters in llvm-g++

Hi Xiaolong, > The compilation substitutes "__position.0" for "__position", as shown below: > > define linkonce_odr void @_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi(%"struct.std::list<int,std::allocator<int> >"* %this, i64 %__position.0, i32* %__x) nounwind ssp { ... } names like this only exist to make the LLVM IR more readable,

Thanks, Duncan. > > The compilation substitutes "__position.0" for "__position", as shown below: > > > > define linkonce_odr void @_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi(%"struct.std::list<int,std::allocator<int> >"* %this, i64 %__position.0, i32* %__x) nounwind ssp { ... } > > names like this only exist to make

Hi Duncan, > > Note that the original parameter (of the function in concern) is of > > type "struct.std::_List_const_iterator<int>", whereas the parameter > > (after the compilation) is of type > > "struct.std::_List_node_base"*. Evidently, llvm-g++ replaces the > > original parameter with its sole field. This is understandable and the >

Hi Xiaolong, > Note that the original parameter (of the function in concern) is of > type "struct.std::_List_const_iterator<int>", whereas the parameter > (after the compilation) is of type > "struct.std::_List_node_base"*. Evidently, llvm-g++ replaces the > original parameter with its sole field. This is understandable and the > LLVM output indicates

Hello all, When I examined the callgraph generated by LLVM via this command: opt -print-callgraph-sccs -dot-callgraph a.out.bc I ran into two confusions: First, there is a "indirect call node" dominating all other nodes (include "main"). My question is: what does this special node serves for? Second, there are two identical functions except that the functions have

Thank you for the prompt response, Matt. On Jan 20, 2014, at 3:03 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > Since 3.4 you need to use the addrspacecast instruction to cast between address spaces. It's possible there are still some places left that haven't been fixed yet to use it instead of creating bit casts. Are you saying you think this is a bug and it should

>> I don't think my backend is modified enough from the MBlaze backend that is >> in the release to be causing this error. I am however looking through the >> various files of the backend to try to find where the calling convention >> might be causing problems with f32 data types. > Form the backtrace it seems like you haven't defined how to return f32 > stuff

On May 26, 2008, at 1:25 AM, Bill Wendling wrote: > On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote: >> On May 25, 2008, at 12:58 AM, Bill Wendling wrote: >> >>> Could you try this (massively hacky) patch out to see if it fixes >>> your >>> problem? >>> >>> >> Alas, it didn't fix the problem: >> > Crumbs. > >

Okay, I've done a lot more testing and I now have a .bc file that compiles for x86, sparc, mips but refuses to compile for the mblaze and powerPC backends because of the calling convention. Is there anyone that would know how to fix the microblaze calling convention or point me in the right direction on how to fix it? The lines in the .bc that I believe to be causing the problem are the

I’ve been developing an optimization pass that uses the address space attribute (__attribute__((address_space(200))) to indicate different kinds of pointers to be treated differently (I’m making them be pointers to a “global” address space as in UPC). However, I’ve hit a snag in the frontend code generator: if I try to make a method call on a pointer with a custom address space, the frontend

Hi Mahesh, On 23 April 2018 at 10:51, Mahesh Attarde via llvm-dev <llvm-dev at lists.llvm.org> wrote: > movq .str at GOTPCREL(%rip),%rdi > movq .str.1 at GOTPCREL(%rip),%rsi That's quite strange. You wouldn't normally expect to access a constant string via the GOT. It looks like LLVM has decided to put the symbols in an odd section, so it'd be a good idea to make sure

Hi I am executing following steps to convert assembly to object code. llc -march=x86-64 -filetype=asm input.ll -o input.s g++ -g -c -o input.s --input.o inshort ll --> llc --> .s -->g++ -->obj original source was something like this { printf(" **** %s ****",str); } input.s turn out to be movq .str at GOTPCREL(%rip),%rdi movq .str.1 at GOTPCREL(%rip),%rsi xorl

Hi Xiaolong, > First, there is a "indirect call node" dominating all other nodes > (include "main"). My question is: what does this special node serves > for? what version of LLVM are you using? I don't think LLVM 2.7 uses a "indirect call node". However it does use a "external node", which is used when a function external to the current

Hey, Considering the following instruction: %20 = load %struct.Node** getelementptr inbounds (%struct.Node* @head, i32 0, i32 0), align 16 ; <%struct.Node*> [#uses=1] What is the type of the first operand of the instruction (i.e., getOperand(0))? I thought the operand is a "GetElementPtr" instruction, however, the predicate "isa<Instruction>()" over

Hi all, In the language specifications, many instructions have this form: <result> = ... So, where is "<result>" defined? Is it an integral part of an instruction? Consider the "getelementptr" instruction: <result> = getelementptr <pty>* <ptrval>{, <ty> <idx>}* How is the "<result>" represented? Best,

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

Hi all, Considering the limit time I have for an implementation, I better ask for your inputs on a few questions. Any answer is to be much appreciated. First, how does LLVM handle the "new statement" of C++? Could any one give me any hint? Second, what properties does the callgraph generated by LLVM has? One property I am interesting in is whether the callgraph is a safe

Hello Reid, Thanks. > Yes, it's an integral part of the Instruction. You can change it by > providing a name when you create the instruction. Following your hint, can I understand in this following way? The name (denoted by "<result>") is actually a referrer to the instruction . Consider this instruction: %this_addr = alloca %struct.String* ;

Hey all, Just wondering if LLVM has any command options or tool to allow for demangling C++ names from the LLVM bitcode? Thanks! Best, Xiaolong

Yes, it's an integral part of the Instruction. You can change it by providing a name when you create the instruction. Reid On Thu, Jun 10, 2010 at 8:34 AM, Xiaolong Tang <xiaolong.snake at gmail.com> wrote: > Hi all, > > In the language specifications, many instructions have this form: > >  <result> = ... > > So, where is "<result>" defined?