search for: northover

Hi all, I’d like to nominate Tim Northover to take over code ownership of ARM target. Thanks, Evan

Hi Tim, Thank you very much for the message. It indeed solved the problem. Thanks On Fri, Nov 8, 2019, 15:05 Tim Northover <t.p.northover at gmail.com> wrote: > Hi Alberto, > > On Fri, 8 Nov 2019 at 06:59, Alberto Barbaro via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Is there any way for avoiding to use llvm.dbg.value within a bc file? > > They're part of LLVM's rep...

...idiv" which is available as an extension for my custom variant. 3. Teach LLVM & Clang about your CPU's features, either locally or upstream. 4. Pass "-mhwdiv=arm,thumb" to Clang (or less if you only have hwdiv in one mode). --Sumanth G -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Tuesday, January 27, 2015 6:44 PM To: Sumanth Gundapaneni Cc: LLVM Developers Mailing List; Roman Divacky; Ana Pazos Subject: Re: [LLVMdev] CPUStringIsValid() into MCSubtargetInfo and use it for ARM .cpu parsing Hi Sumanth, > Shouldn’t the eabi attrib...

...be a better way of achieving your goal. > > David > > > On 08/12/2019 10:19, Alberto Barbaro via llvm-dev wrote: > > Hi Tim, > > My bad, I have installed a newer version of clang and all worked. > > > > Thanks > > > > On Sun, Dec 8, 2019, 10:05 Tim Northover <t.p.northover at gmail.com > > <mailto:t.p.northover at gmail.com>> wrote: > > > > On Sun, 8 Dec 2019 at 09:54, Alberto Barbaro via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > thank...

Oh, that's what I was afraid of. So there is definetly no way to compile for ARC? If so, should I write ARC.h(.cpp) in lib/Basic/Targets in order to make it work? чт, 27 сент. 2018 г. в 14:47, Tim Northover <t.p.northover at gmail.com>: > Hi, > > On Thu, 27 Sep 2018 at 12:41, Павел Безбородов via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > clang -target arc -S test.cpp > > I couldn't find any trace of ARC in the Clang source, so I suspect > it's o...

...t's what I was the solution in my mind. >> But I >> just wanted to know if there was a generic way >> to save >> some code... >> >> On Thu, Apr 16, 2015 at 8:32 PM, Tim Northover >> <t.p.northover at gmail.com <mailto:t.p.northover at gmail.com> >> <mailto:t.p.northover at gmail.com >> <mailto:t.p.northover at gmail.com>>> wrote: >> >> > I understand that I can detect the operation &g...

On 1 July 2015 at 11:34, Russell Wallace <russell.wallace at gmail.com> wrote: > Why do you say spin? You're dismissing all use-cases other than this very narrow one I'd (with my own spin) characterise as "Do What I Mean, I Can't Be Bothered To Get My Code Right". Fair enough, you're arguing in favour of a point; but it's not one I agree with. Tim.

On 4 April 2017 at 06:55, Diana Picus via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On the test-suite, we get 2 timeouts during execution (paq8p and > scimark2). Interesting. I'd not seen those failures in the configurations I'd run. I'll look into them (other than that my best bet for debugging is a kernel panic, this has to be easier!). > On the test-suite, we

On 12 March 2013 14:24, Tim Northover <t.p.northover at gmail.com> wrote: > Could be worth a try. But if that thing really is generating random > numbers I'm not sure replacing one genuine cast-iron random number > with another is the best solution long-term. > The test is initializing srand(1), so in theory, it...

On Thu, Aug 30, 2018 at 11:14 AM, Tim Northover <t.p.northover at gmail.com> wrote: > ... > I don't think it matters for the question at hand, but I tested > AArch64 too and it exhibits the behaviour you were describing. That > is, we'd have problems if an fsub -0.0 was actually CodeGened like > that (it's not,...

...re precision being used than what is in the standard. I came across this issue while looking into the output or different compilers. XL and Microsoft compiler seem to have that turned on by default. But I assume that clang follows what gcc does, and have that turned off. Thanks again, Samuel Tim Northover <t.p.northover at gmail.com> wrote on 07/31/2014 09:54:55 AM: > From: Tim Northover <t.p.northover at gmail.com> > To: Samuel F Antao/Watson/IBM at IBMUS > Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>, Olivier H > Sallenave/Watson/IBM at IBMUS >...

On Wed, 5 Jun 2019 at 13:49, Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I don’t see any particular reason to guarantee that a volatile memcpy will access each byte exactly once. How is that useful? I agree it's probably not that useful, but I think the non-duplicating property of volatile is ingrained strongly enough that viewing a memcpy as a single load and

Hi Tim, My bad, I have installed a newer version of clang and all worked. Thanks On Sun, Dec 8, 2019, 10:05 Tim Northover <t.p.northover at gmail.com> wrote: > On Sun, 8 Dec 2019 at 09:54, Alberto Barbaro via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > thanks for your answer. Unfortunately I'm still using llvm 6.0 and in > llvm-dis I don't see that option. I tried reading the...

On 1 December 2015 at 13:41, Tim Shen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > As a simple solution, when see a LLVM IR bitcast, instead of generating > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) instead? An LLVM bitcast is defined to be equivalent to a store/load pair. Changing that for ISD::BITCAST would be very surprising, and I wouldn't

On Thu, Jul 31, 2014 at 12:31 AM, Tim Northover <t.p.northover at gmail.com> wrote: > > Yeah, exactly those 2 things. I have them in separate patches, but I > think > > we only get the benefit from sized binary literals if we also allow them > to > > initialize multiple bits in another bits<n> type. > &gt...

On Dec 3, 2013, at 2:01 PM, Gary Fuehrer <gfuehrer at defiant-tech.com> wrote: > Today I updated to trunk the toolchain for my work developing on Cortex-M4F. I was super excited to see three commits by Tim Northover that actually attempt to improve the machine code generation for my target, or any ARM target for that matter (as opposed to other important work on compiler correctness or architectural elegance or formatting comment white-space, I mean). Is he alone or are there others working toward such improve...

> *nod*. That's most of what we needed for ARM as well. Should probably > conditionalize it on os darwin for now until it's tested more with a > command line? I'd almost prefer to leave it in for the bugs to be discovered (perhaps after some simple tests of our own). ARM went wirthout FastISel support on Linux for years simply because it was declared Darwin-only. Tim.

On 19 July 2016 at 17:10, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Tim’s repo is using "status checks” and not only protected branch. Yep, I think the main benefit (so far) over just protected branches would be that we can also guarantee sane timestamps on master, which should mean we can reconstruct the llvm-project umbrella uniquely when its script goes down

On 24 July 2015 at 15:00, Tim Northover <t.p.northover at gmail.com> wrote: > GCC seems to be stricter than Clang about the ordering of > __attribute__ (from _LIBUNWIND_EXPORT) and 'extern "C"'. Humpf, that seems to be an old thing. GCC 5.1 on my laptop cope with that just fine. :( thanks! --renato

On 31 May 2016 at 15:42, Tim Northover <t.p.northover at gmail.com> wrote: > A 16-bit division of INT16_MIN by -1 is undefined behaviour but the > original ext/trunc version is well-defined as 0. Sorry, INT16_MIN again actually. The main point still stands though, I think. Tim.