similar to: [LLVMdev] LLVM Exception Handling Changes

In this thread I'm trying to merge two email threads into one, because both discuss the same problem that's troubling us and I would like to reach a conclusion on what would be the best approach. To minimize the size of this thread I only mention the subject of the other two threads: (1) [LLVMdev] Integer promotion of return node operand (initiated by Sachin) (2) [LLVMdev] trouble

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

On May 14, 2008, at 10:43 AM, Alireza.Moshtaghi at microchip.com wrote: > In this thread I’m trying to merge two email threads into one, > because both discuss the same problem that’s troubling us and I > would like to reach a conclusion on what would be the best approach. > To minimize the size of this thread I only mention the subject of > the other two threads: > (1)

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

There is a FIXME part in SelectionDAGLowering::visitRet() that is giving us trouble. And I would like to know how the community has planned for addressing this problem. The current implementation assumes that all C calling conventions require the return value of integer types in the largest register class (for most ports 32-bit). However, this is not the case for our port. We have two register

Hi Sriram, I'm not sure if I understand your question correctly: Do you need to generate code that contains no x87 floating-point instructions altogether, but uses calls into a soft-float library instead? That behaviour can be enabled using the "-soft-float" flag, as far as I know. Or is it only about the fcomi* instructions, which are not supported by pre-Pentium Pro chips? Then I

Chris Lattner wrote: > On Wed, 16 Mar 2005, Morten Ofstad wrote: >> The case which emits code for the special case of comparing against >> constant 0.0 does not return after generating it's code, so the normal >> compare is also generated! As far as I can tell it should return right >> after this: >> >> BuildMI(BB, X86::SAHF, 1); >> >>

On Wed, 16 Mar 2005, Morten Ofstad wrote: > Hello, > > I didn't get any reply to my previous mail about adding floating point > intrinsics to the X86 pattern instruction selector... And I could really need > some help. Sorry about that, it slipped through the cracks. :( > Anyway, I think my confusion was caused partly by an already > existing bug in the instruction

Hello there, I recently started working on the LLVM backend for a target that doesn't support x87 instructions. Currently, I am in the process of completely disabling some x87 instructions such as fcomi, fcompi,... for a specific sub-target. I also do not have SSE enabled for my sub-target, and llvm resorts to fcomi* instructions for FP compare instructions. Is there a way to bypass the

Hi All, Please consider the following case Test case -- -------------------------------------- char a; void fun () { return a; } -------------------------------------- Following disassembly (using llvm-dis) is generated for the above test case -------------------------------------- ; ModuleID = 'first.bc' @a = internal global i8 0 ; <i8*> [#uses=1] define i8 @fun(...) { entry:

On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote: > Promoting the return value is unsafe for bool returns on x86-64, which in the latest revision of the ABI only guarantees that the top 7 bits of the 8-bit register are 0. My comment is a bit off, because the question of what type to make the return value is somewhat orthogonal to the question of which zext assert we should add. Cameron

On Tue, May 12, 2009 at 11:55 PM, Chris Lattner <clattner at apple.com> wrote: > Dan, can you add IVUsers.cpp to the appropriate cmakefile? > > -chris > > > On May 12, 2009, at 10:54 PM, OvermindDL1 wrote: > >> On Tue, May 12, 2009 at 11:40 PM, Chris Lattner <clattner at apple.com> >> wrote: >>> >>> On May 12, 2009, at 10:24 PM,

Regarding patches 5-7, it seems like the mem-map code flow could be more shared. It is a bit challenging to unravel things though. I guess the only specific thing I can really point out is that PcdPciAllowFullEnumeration should be initialized in a different patch, and not within the mem-map init path. -Jordan On Tue, Nov 19, 2013 at 12:38 PM, Wei Liu <wei.liu2@citrix.com> wrote: > This

I know that many ABIs require this for performance purpose, but I haven't seen anything in the standard that suggests promotion of return value to integer. Furthermore, I think the LLVM is supposed to be independent of language. So I'm not sure if SelectionDAGLowering is the right place for this promotion to begin with, TargetLowering class seems more logical; but I'm not sure how.

In ARM the stack should be 8 bytes aligned during function calls. A function that has at least one function call then has a stack size of 8 bytes. PEI::calculateFrameObjectOffsets corretly computes this correctly. The problem is that the alignment is computed before adding space for the call frame size. This is done in emitProlog. Currently the ARM backend has a bug in that it doesn't align

On May 12, 2008, at 8:21 AM, Sachin.Punyani at microchip.com wrote: > > When LLVM constructs the DAG for above case - it tries to promote > (during DAG construction phase - before any combine or legalize phase) > the return node operand to i32. > > I have few doubts here: > 1) If C language requires integer promotion of return value argument > then should it not be done by

> That is irrelevant. The PEI code needs to know how much stack space is > required for each call to allocate and align the stack frame properly. It > gets this info from the ADJCALLSTACK instructions. I see. Looking at PEI::calculateCalleeSavedRegisters shows that the ADJCALLSTACK instructions is used to set up MaxCallFrameSize. Adding debug prints also show that in the example code

Hi Jakob, I have spent last 4 weeks trying to figure out how to implement Interprocedural Register Allocation. I must admit that I was really overwhelmed with LLVM's codebase while trying to figure this out :) There is so much to know! I think I have reached a point where I have some sort of basic understanding of what needs to be done, but I need some help from here on. So here is the

Bruce, Thanks for the explanation. But based on my inspection on the source code, it seems that materialization is related to lazily reading LLVM objects (Module, Function, etc.) into the memory from bitcode files, which is possibly useful during LTO. I’m not sure though. Pei From: <bruce.hoult at gmail.com> on behalf of Bruce Hoult <bruce at hoult.org> Date: Wednesday, June 28,

On 08/26/2010 13:17, Dale Johannesen wrote: >>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >> >> Odd. I thought TCReturn was being lowered. At any rate can you file >> a bug with the .ll file that causes this? > > It should be getting