search for: srhine

...o make clear that it's less obvious whether we'd want -mcpu=native to become a default. It's probably good for some use cases, but really not good for other use cases. I won't be making that change, nor advocate for it. Thanks! Kristof On 31 May 2017, at 17:57, Stephen Hines <srhines at google.com<mailto:srhines at google.com>> wrote: Wow, these are some fantastic results! Android is definitely in favor of fixing the defaults, so this proposal looks great from our perspective. Thanks, Steve On Wed, May 31, 2017 at 5:57 AM, Kristof Beyls <Kristof.Beyls at arm.com...

...done by : // Use the LLVM 3.2 bitcode writer, instead of the top-of-tree version. llvm_3_2::WriteBitcodeToFile(module, OS); Is the corresponding source code also available? if so could you point me to the corresponding file? Thanks again Hongbin On Tue, Aug 2, 2016 at 9:29 PM, Stephen Hines <srhines at google.com> wrote: > Ah, I had missed that. That is great news to hear, actually. The RS team > had already started planning how to adapt their translator to have a 4.0 > (really 3.x) reader for when the dreaded 4.1/5.0 release would make things > difficult. I guess they can rec...

> On Aug 2, 2016, at 8:49 PM, Stephen Hines <srhines at google.com> wrote: > > > > On Tue, Aug 2, 2016 at 8:44 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Aug 2, 2016, at 8:38 PM, Stephen Hines via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at li...

Stephen, does that help you out? From: Mike Edwards <mike at sqlby.me> Sent: Wednesday, November 18, 2020 10:55 AM To: Keane, Erich <erich.keane at intel.com> Cc: Stephen Hines <srhines at google.com>; llvm-dev <llvm-dev at lists.llvm.org>; clang developer list <cfe-dev at lists.llvm.org>; Mehdi AMINI <joker.eph at gmail.com> Subject: Re: [llvm-dev] Renaming The Default Branch On Mon, Nov 16, 2020 at 6:05 PM Keane, Erich <erich.keane at intel.com<mai...

...Is for the past readers/writers when IRBuilder changes, but that doesn't happen all that often. > > Thanks, > Steve > > > At last, we also do not support exception handling:) > > > Thanks. > Hongbin > > On Tue, Aug 2, 2016 at 7:26 PM, Stephen Hines <srhines at google.com <mailto:srhines at google.com>> wrote: > Hi Hongbin, > > On Tue, Aug 2, 2016 at 5:42 PM, Jakub Kuderski <kubakuderski+llvm at gmail.com <mailto:kubakuderski+llvm at gmail.com>> wrote: > I also have a look at the code, looks like it directly parse the...

Ah, I see what you mean. I would have no problem with January 7th being pushed back a while if that helps out your transition. Would that be possible Mike? From: Stephen Hines <srhines at google.com> Sent: Monday, November 16, 2020 6:03 PM To: Keane, Erich <erich.keane at intel.com> Cc: Mehdi AMINI <joker.eph at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; clang developer list <cfe-dev at lists.llvm.org> Subject: Re: [llvm-dev] Renaming The Defau...

...ng is linking to two different version of LLVM at the same time, and use the old version of IRBuilder to build bitcode from new version of LLVM IR. How do you think about this? At last, we also do not support exception handling:) Thanks. Hongbin On Tue, Aug 2, 2016 at 7:26 PM, Stephen Hines <srhines at google.com> wrote: > Hi Hongbin, > > On Tue, Aug 2, 2016 at 5:42 PM, Jakub Kuderski < > kubakuderski+llvm at gmail.com> wrote: > >> I also have a look at the code, looks like it directly parse the bitcode >>> and build in memory representation in a differ...

...renaming the main branch by the end of the year? If we're delaying until the end of January anyway, we'll probably get to our goal *faster* if we wait for the github main branch renaming facility to be available and use it than if we invent our own process. > *From:* Stephen Hines <srhines at google.com> >> *Sent:* Monday, November 16, 2020 6:03 PM >> *To:* Keane, Erich <erich.keane at intel.com> >> *Cc:* Mehdi AMINI <joker.eph at gmail.com>; llvm-dev < >> llvm-dev at lists.llvm.org>; clang developer list <cfe-dev at lists.llvm.org>...

On 9 June 2016 at 19:13, Chris Bieneman <beanz at apple.com> wrote: >> On 9 June 2016 at 18:49, Justin Bogner via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> This all seems pretty sensible. Should we also use the opportunity to >>> split compiler-rt's builtins and profiling/sanitizer/etc runtimes, since >>> we'll be moving things

Motivation At the moment, when targeting armv7a, clang defaults to generate code as if -mcpu=cortex-a8 was specified. When targeting armv8a, it defaults to generate code as if -mcpu=cortex-a53 was specified. This leads to surprising code generation, by the compiler optimizing for a specific micro-architecture, whereas the intent from the user was probably to generate code that is

...this project completed, I overlooked the Holiday aspect. My apologies. So, how about we say we will leave the 'master' branch available in read-only mode until January 28th, 2021? This should give everyone plenty of time to make the transition. > > > *From:* Stephen Hines <srhines at google.com> > *Sent:* Monday, November 16, 2020 6:03 PM > *To:* Keane, Erich <erich.keane at intel.com> > *Cc:* Mehdi AMINI <joker.eph at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; > clang developer list <cfe-dev at lists.llvm.org> > *Subject:*...

> > I also have a look at the code, looks like it directly parse the bitcode > and build in memory representation in a different LLVM version than the > bitcode. Is this correct? According to your description, I guess the BitCodeWriter should be the one > to do the bitcode version downgrade, right? I think so. I don't know much about it and don't want to give you

This timing actually is likely to be more convenient for my downstreams, as most of the devs will be away.That way we can ‘ease’ into our transition with a limited number of devs being affected by it… That said, from a downstream-perspective, it looks like we’ll still be keeping ‘master’ updated for a while, right? > We will lock the master branch and change it to be readonly (with the

FWIW, for our ARM Compiler product, we follow top-of-trunk, not the releases. Next to picking up new functionality quicker, it also allows us to detect regressions in LLVM against our in-house testing quickly, not 6 months later. We find that when we find a regression within 24 to 48 hours of the commit introducing it, it's much cheaper to get it fixed. In my opinion, it would be better

It sounds like the Android RenderScript guys have the most in-the-trenches experience with bitcode incompatibilities. Stephen Hines (CC'd), what sorts of incompatibilities have you guys seen during the 3.x timeline? Would Steven Wu's proposal catch the sorts of incompatibilities that you guys have seen? -- Sean Silva On Thu, Nov 6, 2014 at 4:38 PM, Steven Wu <stevenwu at apple.com>

futimens() is available in Android KitKat. We work extensively with LLVM and this allowed us to remove our ugly workaround for not having this functionality. Steve On Mon, Nov 25, 2013 at 8:30 AM, James Lyon <jameslyon0 at gmail.com> wrote: > Hi, > > I've been trying to get LLVM working as a JIT compiler on Android for a > while. It works now, except that the

On Tue, Nov 4, 2014 at 9:10 PM, Bruce Hoult <bruce at hoult.org> wrote: > On Wed, Nov 5, 2014 at 2:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> > Does Apple support library/middleware providers shipping bitcode instead >> >>> > of object code? >>> >>> No. >>> >> >> Are there ever any plans to do so?

On Mon, Nov 25, 2013 at 12:36 PM, Alp Toker <alp at nuanti.com> wrote: > > On 25/11/2013 18:27, Stephen Hines wrote: > >> futimens() is available in Android KitKat. We work extensively with LLVM >> and this allowed us to remove our ugly workaround for not having this >> functionality. >> > > Hi Steve, > > Is your work on a branch somewhere? >

This is only available for apps that target API level 19 and up. On 18 and lower, the futimens() function won't be available via libc.so. You will need to target API 19 (KitKat) in order to actually use it. If I do an "nm -D prebuilts/ndk/9/platforms/android-19/arch-arm/usr/lib/libc.so", I can see futimens() is present. On the others, it is definitely missing. Steve On Mon, Nov