search for: skrobov

...ms like quite an assumption to make. Clearly, armv6 sub architectures that aren’t v6k will still be v6l in linux. (provided they’re little-endian). I’ve already made that change, and it would be included in any revised diff that I send out. Thanks, - Will > On Jan 6, 2016, at 10:02 AM, Artyom Skrobov <Artyom.Skrobov at arm.com> wrote: > > William, what revision of LLVM is your patch based on? > > The trunk hasn't had ARM_ARCH("armv6hl") since r252903 (Nov 12th) > > > -----Original Message----- > From: William Dillon [mailto:william at housedillon....

...ren’t v6k will still be v6l in linux. (provided they’re little-endian). >>> I’ve already made that change, and it would be included in any revised diff that I send out. >>> >>> Thanks, >>> - Will >>> >>>> On Jan 6, 2016, at 10:02 AM, Artyom Skrobov <Artyom.Skrobov at arm.com <mailto:Artyom.Skrobov at arm.com>> wrote: >>>> >>>> William, what revision of LLVM is your patch based on? >>>> >>>> The trunk hasn't had ARM_ARCH("armv6hl") since r252903 (Nov 12th) >>>...

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any

...that the community has accepted the proposal, and to update the docs? Or is there any formal deadline for objections to be raised? -----Original Message----- From: meinersbur at googlemail.com [mailto:meinersbur at googlemail.com] On Behalf Of Michael Kruse Sent: 17 October 2016 11:46 To: Artyom Skrobov Cc: LLVM Dev; nd Subject: Re: [llvm-dev] Is GCC 4.7 still supported? There was a thread last week[1] when someone also noticed that LLVM doesn't compile with gcc 4.7 anymore. It turned out that it didn't for 3 months already, as there are no more buildbots testing compilation with gcc 4.7....

Hello, About a month ago, I submitted a set of patches for review on llvm-commit. The most controversial of the patches, http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20150622/d104ea7 1/attachment-0009.obj deals with the fact that before ARMv8, the rGPR RegClass in Thumb encodings didn't include SP; but from ARMv8 onwards, it does include it. RegClass membership is

Taking the suggestions of the group under consideration, I’ve generated a new diff. The thing to note is that armv6l is now treated identically to armv6hl. I’ve also added a unit test. This seems to me to be the least invasive method, and holds to existing conventions as closely as possible. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name:

...--------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at 10:16 PM Subject: buildbot failure in LLVM on sanitizer-x86_64-linux-bootstrap To: Adrian Prantl <aprantl at apple.com>, Ahmed Bougacha < ahmed.bougacha at gmail.com>, Artyom Skrobov <Artyom.Skrobov at arm.com>, Bob Wilson <bob.wilson at apple.com>, Bruno Cardoso Lopes <bruno.cardoso at gmail.com>, Chad Rosier <mcrosier at codeaurora.org>, Chris Bieneman <beanz at apple.com>, Daniel Jasper <djasper at google.com>, David Blaikie <dblaikie a...

>> Going back through SVN history, I cannot find any evidence that ARMv6L ever existed. > > Oh, my bad!! I was thinking of ARMv7l... :/ > > Nevertheless, I'll leave you guys to review this one, as I lost touch with the parser a while ago. Ah, I see: ARMv7L is now an alias for ARMv7A. So, if William has to add support for ARMv6L, I'd suggest he adds it as an alias, and

Hello, http://llvm.org/docs/GettingStarted.html#software lists "GCC >=4.7.0" among requirements for building LLVM. However, my attempt of building LLVM+Clang with gcc 4.7.3 has failed with a multitude of errors, such as: lib/LTO/Caching.cpp:74:7: error: looser throw specifier for 'virtual llvm::lto::localCache(std::string, llvm::lto::AddFileFn)::<lambda(unsigned int,

>> However, because the DefaultTargetTriple is armv6l-unknown-linux-gnueabihf, >> and llvm didn’t know about v6l, it would fail to match and canonicalize to armv6. >> I added the notion of v6l to llvm to address this. > > ARMv6l was definitely there once. I'm not sure what happened. > > I'm copying the ARM folks that did most of the recent changes in hope

On May 15, 2014, at 3:22 AM, Artyom Skrobov <Artyom.Skrobov at arm.com> wrote: > Hello, > > Carrying on this conversation from llvm-commits: > >>>>> Would it be reasonable if we name both SwapByteOrder() -- it's > difficult >>>>> to describe their purpose in any other way -- and make...

On May 26, 2014, at 8:21 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, May 26, 2014 at 7:41 PM, Andrew Trick <atrick at apple.com> wrote: > On May 26, 2014, at 5:02 PM, Chandler Carruth <chandlerc at google.com> wrote: > >> >> On Mon, May 26, 2014 at 4:43 PM, Andrew Trick <atrick at apple.com> wrote: >> This has been

...d have asked the linux guys not to invent a new triple. It's in linux now, and `uname -a` is a very standard way of obtaining the host's triple. James On Tue, 5 Jan 2016 at 08:34 Tim Northover via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4 January 2016 at 14:42, Artyom Skrobov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Ah, I see: ARMv7L is now an alias for ARMv7A. > > The "armv7l" comes directly from the Linux kernel I believe: "armv7" + > "little-endian" (arch/arm/kernel/setup.c:638 ish). I'm not enti...

Hello, As part of enhancing atomic operations in the ARM backend, we need to extend the Ops array in AtomicSDNode. This array is a private member of AtomicSDNode, so it's only accessible within 85 lines of code, none of which have anything to do with its size. Therefore, increasing the size of Ops shouldn't at all affect the behaviour of LLVM, we supposed. Much to our surprise, this