similar to: Passing arguments to var args function

Hey Tim, thanks for the quick answer, this looks exactly like what I was trying to achieve, I was hoping there was something more clean, I was wondering how the community would accept a change in the TD, if the code at CallinvConvLower.cpp:138 would've passed the IsFixed flag to the AssignFn then all those workarounds wouldn't be needed, this example is only one of a few I can think of for

Hey Paul, first of all thank you for taking the time to answer me, if I understand you correctly, I need to modify the instruction it self so one of it's operands is a symbol, and then at MC layer handle that symbol and add an entry to the symtab for that label? What kind of symbol should I use doing such thing? external symbol or MCSymbol? I was trying to find where in the code during the MC

Hi Liad, I'm not an expert in MC, but what you describe doesn't sound any different from how you would handle a branch instruction. Create an MCSymbol that represents the address of the target instruction; use that symbol as an operand in the referencing instruction; emit the symbol as a label just prior to emitting the target instruction. The second and third steps can occur in either

Hi everyone, I am fairly new to LLVM, I'm working on a new backend. I am trying to add information to a specific instruction using the .symtab in the ELF format. I've been searching through the LLVM source code trying to find a way to do such a thing. Can anyone help me with some directions or point me to some documents in the matter. Thanks, Liad. -------------- next part --------------

Hey all, There seems to be two conventions for git repo directory layout. The official docs suggest the following tree. http://llvm.org/docs/GettingStarted.html#git-mirror llvm (llvm repo) -> tools -> clang (clang repo) -> lld (lld repo) etc. However various llvm-project repos, suggest a different layout: https://github.com/llvm-project/llvm-project-20170507

Hi everyone, I'm faily new to LLVM, I'm working on a new backend. In my backend, one of the requirements is to split a BB on every call, I considered putting some kind of pseudo instruction using the TargetLowering::LowerCall function. Before going said path, I was wondering if there is some way to split the BB before the SelectionDAG is generated, this way the call instruction would be

I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. > On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This question came about through reviewing work from Leslie Zhai on GlobalISel > support for RISC-V, which also motivated me to revisit code which I've always > felt was a

Matt, Thanks for the response. Is there an example in the code somewhere of doing the intrinsic ID method? I don't need to put it a lot of places so I'm not sure it warrants adding a node. Thanks. On Tue, Feb 2, 2016 at 12:35 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Feb 2, 2016, at 09:29, Ryan Taylor via llvm-dev < > llvm-dev at lists.llvm.org>

Hi All, While compiling libgcc, I find I have to deal with UMULO (overflow-aware unsigned multiplication) SDNode. UMULO returns the result of multiplication, and a boolean indicating overflow occurred or not. Our target's multiply instruction doesn't care (detect) overflow. I am wondering if I can always set the boolean to false. I am not sure about this as I see AArch64 [1] seems

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

The first layout is older, and the second is newer. Going forward, things are likely to move around. The second layout is more flexible because it doesn't put any repo inside another repo, so I would recommend adopting it. At the very least, using it will put you in a good position to adapt to any future layout changes. On Mon, Feb 19, 2018 at 1:36 AM Liad Mordekoviz via llvm-dev <

This question came about through reviewing work from Leslie Zhai on GlobalISel support for RISC-V, which also motivated me to revisit code which I've always felt was a bit clunky. Calling convention lowering in LLVM is typically handled by functions conforming to the CCAssignFn typedef: typedef bool CCAssignFn(unsigned ValNo, MVT ValVT, MVT LocVT,

I"m getting build errors I think from one of your patches O tjoml. You need to have a build area that builds with clang and does warnings as errors to avoid these issues on putback. here is my configure step for example: /home/rkotler/llvm_trunk/configure --enable-werror --prefix=/home/rkotler/ll vm/install CC=/home/rkotler/llvm_3_2/install/bin/clang CXX=/home/rkotler/llvm_3_

I think your users will be very upset if you don't set the boolean return value correctly :-) Whatever work it takes to determine the correct value for it, if the user code doesn't need/use that value then the dead code will be eliminated later. But if they need that return flag then they will want it to be correct! You may need to use a multiply instruction that returns a

If your target has a cheap count-leading-zeros instruction, you'd be able to determine whether an unsigned multiply will overflow or not, in most cases, without doing the long version of the multiplication. This is because an N-bit number times an M-bit number will produce a result that is either N+M bits wide or N+M-1 bits wide. If an N+M bit result will fit in your result type, you are

After a long processing, I was able to create a version of a small C# class that was able to emulate the rproxy by P/Invoke. This is mostly to find a workaround a performance problem of the StatConnector. It's almost work but ... I have strange memory exception when I call the print function. The variable seems to not survive from one call to the other. As there is no debug symbol for

It is r195843 and fixed in r195905, FYI. 2013/11/29 Reed Kotler <rkotler at mips.com>: > I"m getting build errors I think from one of your patches O tjoml. > > You need to have a build area that builds with clang and does warnings as > errors to avoid these issues on putback. > > here is my configure step for example: > /home/rkotler/llvm_trunk/configure

I'm still seeing this problem. On 11/28/2013 09:37 AM, NAKAMURA Takumi wrote: > It is r195843 and fixed in r195905, FYI. > > 2013/11/29 Reed Kotler <rkotler at mips.com>: >> I"m getting build errors I think from one of your patches O tjoml. >> >> You need to have a build area that builds with clang and does warnings as >> errors to avoid these

Hi, When using Wine to run Windows ARM64 executables on Linux, there's one major ABI incompatibility between the two; Windows treats the x18 register as the reserved platform register, while it is free to be clobbered anywhere in code on Linux. The Wine code sets up this register before passing control over to the Windows executable code, but whenever the Windows code calls a function

As many of you will know, handling of struct arguments in LLVM is actually slightly more fiddly than you might expect. For targets where aggregates are always passed on the stack it's easy enough, the Clang ABI code marks these arguments as byval and the call lowering code in LLVM will copy the object to the stack when needed. There are more options for when the target has more complex ABI