similar to: [LLVMdev] Problem selecting the correct registers for a calling convention

Hi Job, > This issue is basically that I cannot find a way to distinguish two i16 > arguments from one i32. Is there a way to do this in LLVM? Preferably using > tablegen, of course:-) I think the property you want is "isSplit" (or, from the TableGen side CCIfSplit). This gets applied to the first of those i16s that are produced. Unfortunately I can't think of much you

I'm currently working on the MSP430 backend and I have some problems implementing the calling convention. It's a 16-bit architecture which dictates that arguments should be passed in registers R15-R12. Therefore, I have something like this is a .td file: CCIfType<[i16], CCAssignToReg<[R15W, R14W, R13W, R12W]>> 32-bit arguments should be passed in R14:R15 (R12:R13).

Hi, I am trying to write a LowerCALL() function for my (custom) target ISA. All I need to do is map a CALL instruction directly onto an SDNode that takes an equal number of arguments (very much alike intrinsics, except that these are custom to my target.) I do not need to implement any call sequences, stack frames etc. I get the following assertion failure: llc: LegalizeDAG.cpp:834:

Hi Nickhil, The Legalizer expects lower'd call is the node that produce the same number of values as the non-lowered node. That's what the assertion is checking. Take a look at the LowerCall routine for any other targets. You will see that in the non-void function case, it returns a MERGE_VALUES, i.e. all the results merged along with the chain. Cheers, Evan On Nov 15, 2006, at

Hello, I'm having trouble getting the function prototype of an ExternalSymbolSDNode inside TargetLowering::LowerCall(), this way i could get the original argument sizes before they're legalized into smaller parts. I need this sort of information because depending on the originaltypes of the arguments i need to use some regs or others. I tried using the isSplit flag in ArgFlagsTy but it

I'm a new LLVM developer contributing patches for the AVR platform and I'm trying to understand which parts of the code base are malfunctioning in my case. This LLVM IR... define hidden i32 @setServoAngle3(i32) local_unnamed_addr { entry: %1 = call i32 @myExternalFunction1(i32 %0, i32 119) ret i32 %1 } declare i32 @myExternalFunction1(i32, i32) Is being lowered to this assembly

Le 15/03/2012 03:07, Akira Hatanaka a écrit : > If you need llvm::Argument, this returns the iterator pointing to the > first argument: > > Function::const_arg_iterator Arg = > DAG.getMachineFunction().getFunction()->arg_begin(); Thanks Akira. Ivan > > On Wed, Mar 14, 2012 at 8:16 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi, >> >> How

Hi Evan, On Wed, Nov 15, 2006 at 10:17 -0800, Evan Cheng wrote: > Hi Nickhil, > > The Legalizer expects lower'd call is the node that produce the same > number of values as the non-lowered node. That's what the assertion > is checking. > > Take a look at the LowerCall routine for any other targets. You will > see that in the non-void function case, it

Hi all, I'm rather new to LLVM and intend to dive into partial evaluation with LLVM. I tried to run the example from http://llvm.org/devmtg/2008-08-23/llvm_partial.pdf, which worked after some adaptations, which were necessary, because LLVM evolved since the slides were made. However, I also tried to get the same example running as an optimization pass following the instructions in

r175088 attempted to fix gcc inline asm compatibility with 64-bit operands by forcing these into even/odd register pairs the same way gcc always allocates such values. While the fix appears to work as such, it is not always activated when required. The patch makes the assumption that any inline asm statement relying on the even/odd allocation will make use of the %Hn syntax to reference the high

I had the same issue as both of you when I was implementing this for my backend. In LowerCall you can get the callee prototype info when the Callee SDValue is a GlobalAddressSDNode doing cast<Function>(G->getGlobal()) (where G is GlobalAddressSDNode *G = dyn_cast<GlobalAddressSDNode>(Callee)), but this won't work when it is a ExternalSymbolSDNode, for that case i had to add

On Wednesday 04 Apr 2012 12:41:49 Patrik Hägglund H wrote: > Hi Tim, > > > So I've come to the conclusion that the real flaw is LLVM > > not exposing enough information to the target-dependent > > backend code for it to do the right thing. > > We also had this problem. You might find this patch useful as a starting > point:

If you need llvm::Argument, this returns the iterator pointing to the first argument: Function::const_arg_iterator Arg = DAG.getMachineFunction().getFunction()->arg_begin(); On Wed, Mar 14, 2012 at 8:16 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi, > > How can I get the llvm-type of the formal argument while lowering it ? > > My target needs to map pointer and

Hi, I am doing a project involving checking a called specific function’s argument. Suppose that the function is int f(const char* str). When I am analyzing such a snippet: f("hello") , then compiled by Clang, I will have the “hello” as a *Constant Array* in the IR code. My goal is to call APIs of LLVM to get the “hello” from IR code. Now suppose the I got the llvm::Function* fn from

It is good to see this ----- Forwarded message from syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> ----- Date: Sat, 25 Mar 2017 05:54:09 -0700 From: syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> To: Syslinux commits mailing list <syslinux-commits at zytor.com> Cc: ams at ludd.ltu.se Subject: [syslinux:master] mbr/isohdpfx.S: correct pointer for heads/sectors

Hi All, I'm trying to compile the attached code(gdb11531.c) with latest clang with -O0 on ARM. Clang seems to be reordering the instructions in case of constant nodes(for ARM) even when O0 is specified resulting in few wrong information when debugging through GDB. I had few queries,would be great if someone could clarify the same - In the given assembly code, the instructions where constant

Hi Philip, The error happens when the program finishes and it automatically calls the destructors, so it is not an error specifically inside my program. Here's the full code: #include "llvm/ExecutionEngine/ExecutionEngine.h" #include "llvm/ExecutionEngine/MCJIT.h" #include "llvm/IRReader/IRReader.h" #include "llvm/Support/TargetSelect.h" #include

Hi, don't know if this is the right list. Please post a better place, otherwise. I'm currently writing a LLVM ModulePass and ran into strange segfaults or endless loops within LLVM. My main question is, if this is a programming error or API misuse from me or a LLVM bug? Here is some minimal code, that triggers the bug: ---------------- class DebugPass : public ModulePass { public:

Hi, How can I get the llvm-type of the formal argument while lowering it ? My target needs to map pointer and non-pointer parameters to different registers. In addition, parameter lowering is address space dependent (another reason why I need such information). Looking at the DAGBuilder, I found that it is dropping it when translating llvm-types to BE types. Even if the base type is saved

Our target also use different registers for pointer and non-pointer parameters. > If you need llvm::Argument, this returns the iterator pointing to the > first argument: DAG.getMachineFunction().getFunction() only works in LowerFormalArguments (there it returns the callee), not in LowerCall (where it returns the caller, rather than the callee). You need to pass more information about the