similar to: [LLVMdev] calling conventions

Hi Chandler, That's embarrassing how weird this part of clang is. I have a provisional patch which fixes the problem but underlines clang's problems. I will submit it tonight for comments. суббота, 18 октября 2014 г. пользователь Chandler Carruth написал: > > On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov < > anton at korobeynikov.info >

Hi Sandeep, >> The ARM backend now supports struct byval for APCS. Extending it to support AAPCS shouldn't be too difficult. Alas, I won't have time to revisit this in the near future. > > It's slightly unclear to me what byval means for an ABI that passes > some structs in registers, such as AAPCS-VFP. I think in that case the front-end is supposed to extract the

> On Mar 2, 2016, at 11:33 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 2 March 2016 at 18:48, John McCall <rjmccall at apple.com> wrote: >> The frontend will not tell the backend explicitly which parameters will be >> in registers; it will just pass a bunch of independent scalar values, and >> the backend will assign them to registers or the stack

Hello, I recognized that compiler-rt's the implementation of __aeabi_memcpy simply branches to memcpy. The implementation of memcpy is not provided. So an externally provided memcpy () has to be used. (also applies to memmove, memset, memclr) On ARM I have seen implementations of memcpy () using floating-point registers (if compiled with NEON support). The is perfectly legal, as memcpy ()

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

Hi all, I was wondering if ARM aapcs calling convention defines how to pass small vectors as parameter to a routine. By small vectors, I mean with size less than a 32-bit integer. For instance if we consider following code: ; ModuleID = 'smallvect.ll' define arm_aapcscc void @foo(<2 x i8>* %p) { L.entry: %0 = load <2 x i8>* %p call arm_aapcscc void @bar(<2 x

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 02/25/2014 02:38 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 09:30 AM, Richard Sandiford wrote: >>> reed kotler <rkotler at mips.com> writes: >>>> On 02/24/2014 04:42 PM, Eric Christopher wrote: >>>>> On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at

In the following example with gcc style builtins, in once case llvm.powi.f64 is emitted and in the other just a call to library function powf. ~/llvm/build/Debug+Asserts/bin/clang -S -emit-llvm pow1.c Why is that? Is there a way to force the call to an llvm style builtin? Tia. Reed -------------- next part -------------- A non-text attachment was scrubbed... Name: pow1.c Type: text/x-csrc

On 06/10/2014 05:51 PM, Pete Cooper wrote: > Hi Reed > > You can do this on the instruction itself by telling it 2 operands > must be the same register. For example, from X86: > > let Constraints = "$src1 = $dst" in > defm INSERTPS : SS41I_insertf32<0x21, "insertps">; > > Thanks, Hi Pete, Sorry. I should have been more specific. I'm

I see what my problem is here.... I'll continue to move further. Seems like Richards fix is still okay. On 02/25/2014 02:42 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:41 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 02:38 PM, Eric Christopher wrote: >>> On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote:

On 06/04/2012 05:17 PM, Daniel Berlin wrote: > Can we get back to the substantive discussion about your ideas for > lessening the technical debt? The lessening requires enlisting people that are willing to do this as opposed to doing fun science like cool optimization. I,for example, find the documentaiton, cleanup and refactoring to be interesting so I don't feel cheated to work on

We are starting to move to using llvm/clang x86 as the starting point for mips native compilers. It's important to make sure that gcc cross compilers can do this too but sometimes there are issues there; especially now as c++11 is moving into the foreground. We are working to also make sure this works. As 3.5 llvm is probably around the corner; our use of clang/llvm for this starting

Is there a simple way to just change the opcode of a machine instruction. I have a lot of long/short pairs where when I know the offset, i can replace the long version with the short version. Tia. REed

FWIW, I'm putting together (hopefully to be done by the end of this weekend) a substantial refactoring of the TableGen backend API along with shiny new documentation (reStructuredText with sphinx) of all of TableGen, including documentation about how to write backends and---depending on how adventurous I get---a more detailed coverage of the syntax. Also, Reed, in your TableGen talk, IIRC,

On 02/24/2014 04:42 PM, Eric Christopher wrote: > On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at mips.com> wrote: >> I need to leave soon and will take a look in the morning. >> >> I did look at the autoconf input files configure.ac >> >> There is a disable-zlib but not a disable-valgrind, even though it seems >> like there used to be.

I would like to make the following member of AsmPrinter be protected void EmitInlineAsm(StringRef Str, const MDNode *LocMDNode = 0, InlineAsm::AsmDialect AsmDialect = InlineAsm::AD_ATT) const; I have some stubs that I want to emit in MipsAsmParser . Are there any objections to doing this? Reed

Well, differences of opinion is what makes horse races. Reed On 06/04/2012 04:57 PM, Daniel Berlin wrote: > On Mon, Jun 4, 2012 at 7:53 PM, reed kotler<rkotler at mips.com> wrote: >> On 06/04/2012 03:25 PM, Daniel Berlin wrote: >>> I'm pretty sure neither llvm nor clang have any technical debt at all. >>> >>> On Mon, Jun 4, 2012 at 5:18 PM, reed

If you can't make an executable test from C or C++ code then how do you know something works. Just by examination of the .s? On 09/30/2014 03:18 PM, Reed Kotler wrote: > If I wanted to call this function that they generated by hand, from C or > C+ code, how would that be done? > > if have seen cases where a real boolean gets generated but it was > something fairly involved.

Hi Sean, Glad to hear there is clean up of tablegen going on. Just for the record, I don't know what you are referring to regarding some comment of mine at my talk about 10K LOC. I don't know how big tablegen is itself nor how much code has been written in it so I would not have ventured such a guess. The idea of totally replacing the tablegen language came up at the talk during the