similar to: [LLVMdev] llvm-abi: A library for generating ABI-compliant LLVM IR

Hi Reid, Thanks for your response. The issue is that every LLVM frontend needing ABI compliance has to re-implement the same target-dependent logic, which is a significant burden; the ABI compliance code inside Clang isn't really usable for other frontends as-is. We haven't got many good options here :-). I think a lot of people would've hoped that LLVM would provide the means for

On Tue, 30 Jun 2015 at 06:02 Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Stephen Cross" <scross at scross.co.uk> > > To: "Reid Kleckner" <rnk at google.com> > > Cc: "Clang Developers List" <cfe-dev at cs.uiuc.edu>, "LLVM Developers > Mailing List" <llvmdev at

On Wed, 1 Jul 2015 at 08:19 Stephen Cross <scross at scross.co.uk> wrote: > Hi everyone, > > I was wondering if anyone could answer the questions in my first > email. These were: > > * Why does Clang generate 8 byte alignment for 16+ byte arrays on > x86-64, even though the AMD64 ABI seems to require 16 byte alignment? > * Clang has some logic in

On Tue, Mar 29, 2016 at 9:17 AM, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Mon, Mar 28, 2016 at 5:14 PM, Michael Nicolella via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Thanks for the explanation. It's good to hear the situation isn't felt to >> be ideal. >> >> The details here are going to be sensitive

On Mon, Mar 28, 2016 at 5:14 PM, Michael Nicolella via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for the explanation. It's good to hear the situation isn't felt to > be ideal. > > The details here are going to be sensitive to the OS + target that I'm > compiling for, right? So the effort here will be to understand and get > right the calling

Hi everyone, Currently it looks like metadata is used in LLVM IR essentially as an 'optional extra', in that any pass is allowed to remove metadata (though preserving metadata is useful) and the program should remain valid. In other words the metadata only communicates information about code quality or associated information rather than issues relevant to correctness. First question: Is

> > This seems interesting, I have a few questions: > > > Has the ISA been finalized yet or is it still a work in progress? Will > there be a fixed number of registers? > The design document has a high-level idea of the ISA, or rather of the AST we're thinking of going with: https://github.com/WebAssembly/design/blob/master/AstSemantics.md The final encoding isn't

Thanks for the explanation. It's good to hear the situation isn't felt to be ideal. The details here are going to be sensitive to the OS + target that I'm compiling for, right? So the effort here will be to understand and get right the calling convention details for each supported target, yes? Is there any current plan to change the way this works, or is it more of a dreamy cleanup

On 15 February 2011 18:30, David A. Greene <greened at obbligato.org> wrote: > { int32, int8, { int8 } } > > Do I understand you correctly? Hi David, I'm actually looking for answers, not requesting features... ;) That structure would actually solve the problem for this specific case, but not for the general case. There are far too many exceptions to be worth make a special

Renato Golin <renato.golin at arm.com> writes: >> There are ways to do that without losing too much information.  For >> example, we render the above without using arrays at all: >> >> %I = type { i32, i8, i16 } >> %J = type { %I, i8, i16 } > > Not if you follow the Itanium C++ ABI. > > In your example it works because { i8, i16 } pads nicely to 4

On 4 Jun 2020, at 0:54, James Y Knight via llvm-dev wrote: > While MLIR may be one part of the solution, I think it's also the case > that > the function-ABI interface between Clang and LLVM is just wrong and > should > be fixed -- independently of whether Clang might use MLIR in the > future. > > I've mentioned this idea before, I think, but never got around to

[snip] > The ABI boundary lowering requires types to be broken down further into > 'legal types' that can be mapped to registers. The secondary breakdown is > currently handled by TargetLowering::LowerCallTo() calling > getRegisterType() and getNumRegisters(). Most ABIs are defined in terms > of C types, not LLVM IR types, so there is a close connection between the C >

Hi all, I'm trying to understand which ABIs are supported in the PowerPC backend and I'm getting a bit confused. Here's what I've gathered so far alongside with some questions. - In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI. - The CodeGenerator documentation claims that the AIX PowerPC ABI is followed (with some deviations). Is this refering to the DarwinABI? -

On 19 October 2012 17:00, Duncan Sands <baldrick at free.fr> wrote: > That said, I also don't like the idea of filling the IR with tons of target > specific stuff. In this case, I think it's even worse than "aapcs" or "fastcall", that are target dependent, but at a higher level. Proposing at which register each variable will be, forces the front-ends to

David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes: > I'm not opposed to this in principle, and actually I'd quite like to > move in this direction and remove our reliance on undocumented and > inconsistent conventions between the back end and the front end for > conveying information about ABIs. For example, returning two 32-bit > integers or a pair of

----- Original Message ----- > From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com> > To: "David Wiberg" <dwiberg at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, July 30, 2014 2:29:22 PM > Subject: Re: [LLVMdev] [PowerPC] ABI questions > > Hi David, > > > I'm trying to understand which ABIs are supported in the

On Sat, Oct 20, 2012 at 10:37 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 19 October 2012 17:00, Duncan Sands <baldrick at free.fr> wrote: >> That said, I also don't like the idea of filling the IR with tons of target >> specific stuff. > > In this case, I think it's even worse than "aapcs" or "fastcall", that > are

It's worth noting that gcc chose *not* to support any ABI changing flags. I'm in favor of avoiding flags here. We can simply document that clang 3.3 and earlier works with gcc 4.6 and earlier, and clang 3.4+ works with gcc 4.7+. On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com > wrote: > Mingw switched abis with the release of gcc 4.7 >

David Blaikie <dblaikie at gmail.com> 於 2020年1月14日 週二 上午2:15寫道： > > > On Mon, Jan 13, 2020 at 6:12 AM Zakk <zakk0610 at gmail.com> wrote: > >> >> >> David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> 於 2020年1月11日 週六 >> 上午2:03寫道： >> >>> Ah, OK - thanks for walking me through that. >>> >>> Fair enough, I

This is a patch to forward-port a Xend behaviour. Xend writes IO ABI used for all frontends. Blkfront before 2.6.26 relies on this behaviour otherwise guest cannot boot when running in 32-on-64 mode. Blkfront after 2.6.26 writes that node itself, in which case it''s just an overwrite to an existing node which should be OK. In fact Xend writes the ABI for all frontends including console