search for: andya

...make sure that if users gave us compatible defs (mainly: same source, but optimized in one CU and not in another), we wouldn't screw things up. -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Thursday, February 25, 2016 11:36 AM To: Andy Ayers <andya at microsoft.com> Cc: Hal Finkel <hfinkel at anl.gov>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics") On Thu, Feb 25, 2016 at 11:27 AM, Andy Ayers <andya at microsoft.com> wrote...

...ith different IPA results (for example if a callee of the linkonce is available in one CU but not the other). -- Mehdi > > -----Original Message----- > From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] > Sent: Thursday, February 25, 2016 11:36 AM > To: Andy Ayers <andya at microsoft.com> > Cc: Hal Finkel <hfinkel at anl.gov>; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics") > > On Thu, Feb 25, 2016 at 11:27 AM, Andy Ayers <andya at mic...

On Thu, Dec 17, 2015 at 9:21 AM, Andy Ayers <andya at microsoft.com> wrote: > While your bb count distribution is extremely likely to be some kind of power-law like distribution, it's not guaranteed. > > Also you might think about operations that can amplify (rerolling) or appear to amplify (TRE) or diminish BB counts, and how you...

I'm probably missing something obvious here, but naively, this makes it kind of awkward to have mutable thread local state... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141212/53b577ae/attachment.html>

On Thu, Feb 25, 2016 at 11:27 AM, Andy Ayers <andya at microsoft.com> wrote: > For non-LTO compiles: block bottom-up propagation of facts that > depend on optimization levels -- eg register kills and parameter usage > summaries. Allow other IP information to flow upwards, since at least > in our world all comdat-foldable definitions a...

On Wed, Dec 16, 2015 at 6:00 PM, Andy Ayers <andya at microsoft.com> wrote: > I’ve done similar rankings with profile data and found it worked out pretty > well. > > > > In my case it was ranking function hotness but the idea was similar: sort by > weight, compute various percentile cutoff points, and use those to classify....

...keyboard controller that does to piano keys what 3D touch does to the iPhone* <http://www.slashgear.com/roli-seaboard-rise-is-like-3d-touch-for-musicians-11404216/>*”. Now available for preorder at **www.roli.com* <http://www.roli.com/>*.* On 23 November 2015 at 16:27, Andy Ayers <andya at microsoft.com> wrote: > Microsoft compilers have for quite a while now assumed the code you > compile is going to be linked into PE images, which are limited to 4GB. So > they assume a small memory model and use 32 bit relocations. If at link > time it turns out your export is fr...

Forgive my newbness. I'm pretty fresh to Linux, but trying to port some reasonably sizable windows apps that I have written. Certainly my gui apps appear to work directly with wine. I also have stuff that makes more sense to use with winelibs. I've had no significant difficulties setting up and compiling bits an pieces, basically just to get my orientation sorted. One of my apps is an

...hat this is a purely theoretical problem. -- Sanjoy _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev%0a&data=01%7c01%7candya%40microsoft.com%7cf0dc286d1dc04d5daf9408d33e0d7a98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZK9BbJxV6%2bcAQn%2ftdy3%2b%2fHyOA7BR5QclvKO1egIap0w%3d

...istmail at philipreames.com] Sent: Thursday, August 27, 2015 11:01 AM To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com> Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers <andya at microsoft.com>; Russell Hadley <rhadley at microsoft.com> Subject: Re: RFC: alloca -- specify address space for allocation >>Managed language clients typically use address space 1 to represent GC-pointers. > This is not an entirely accurate statement.  There are currently one...

The LLILC project does not require direct interaction with the PDB, so it’s not part of our plans. The JIT uses a special reporting format to communicate debug info (frame info and machine->IL mappings) back to the CoreCLR EE. The debugger joins this with the frontend-produced debug information (IL->source and logical frame offset->local, which is in a PDB) to complete the picture.

...listmail at philipreames.com] Sent: Thursday, August 27, 2015 1:47 PM To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com> Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers <andya at microsoft.com>; Russell Hadley <rhadley at microsoft.com> Subject: Re: RFC: alloca -- specify address space for allocation For the record, at least two other implementation strategies to address the original problem have been discussed. Option 1 (Rejected) - Explode the stack based ob...

In other compilers I've worked on there were special pseudo instructions (or similar mechanisms like adding extra source operands to returns) that allowed you to artificially extend lifetimes of values. For instance we might have a requirement that a certain local (say the 'this pointer') remain live throughout the method. Is there anything like this in LLVM? -------------- next part

...s.com] > Sent: Friday, August 28, 2015 9:38 AM > To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm- > dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com> > Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers > <andya at microsoft.com>; Russell Hadley <rhadley at microsoft.com> > Subject: Re: RFC: alloca -- specify address space for allocation > >> I think for the use case you are outlining, an addrspacecast is the correct IR model -- >> you're specifically saying that it is OK...

Thanks for the pointer, it's always helpful to be able to see how another project solved similar problems. > On Mar 8, 2016, at 11:24 AM, Andy Ayers <andya at microsoft.com> wrote: > > FWIW, LLILC (https://github.com/dotnet/llilc) uses MCJIT with a custom memory manager to hold onto the binary bits and discard the rest. > > As far as I know it doesn't leak, though we don't blow away the context, so that grows a bit over time....

...without error. >> >> >> >> Thanks very much for any response! >> >> >> >> (Sorry for the slow reply, was trying to get something as minimal as possible for you to look at) >> >> >> >>> On 2 Oct 2015, at 19:45, Andy Ayers <andya at microsoft.com <mailto:andya at microsoft.com>> wrote: >> >>> >> >>> If LLVM is generating the x64 code and you have specified a large code model, you should not see any 32 bit relocations. >> >>> >> >>> So it would be interesti...

...rror. >> >> >> >> Thanks very much for any response! >> >> >> >> (Sorry for the slow reply, was trying to get something as minimal as >> possible for you to look at) >> >> >> >>> On 2 Oct 2015, at 19:45, Andy Ayers <andya at microsoft.com> wrote: >> >>> >> >>> If LLVM is generating the x64 code and you have specified a large >> code model, you should not see any 32 bit relocations. >> >>> >> >>> So it would be interesting to determine what kind of...

...13 version 12.0.40629.00 Update 5 Running the same code without llvm-rtdyld.exe (i.e. non-JIT) does so without error. Thanks very much for any response! (Sorry for the slow reply, was trying to get something as minimal as possible for you to look at) > On 2 Oct 2015, at 19:45, Andy Ayers <andya at microsoft.com> wrote: > > If LLVM is generating the x64 code and you have specified a large code model, you should not see any 32 bit relocations. > > So it would be interesting to determine what kind of relocation you are seeing and where it came from. > > -----Original...

...om: Swaroop Sridhar > Sent: Saturday, August 29, 2015 12:30 AM > To: Philip Reames <listmail at philipreames.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com> > Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers <andya at microsoft.com>; Russell Hadley <rhadley at microsoft.com> > Subject: RE: RFC: alloca -- specify address space for allocation > >> -----Original Message----- >> From: Philip Reames [mailto:listmail at philipreames.com] >> Sent: Friday, August 28, 2015 9:38 AM &gt...

...ode without llvm-rtdyld.exe (i.e. non-JIT) does so without error. >> >> Thanks very much for any response! >> >> (Sorry for the slow reply, was trying to get something as minimal as possible for you to look at) >> >>> On 2 Oct 2015, at 19:45, Andy Ayers <andya at microsoft.com> wrote: >>> >>> If LLVM is generating the x64 code and you have specified a large code model, you should not see any 32 bit relocations. >>> >>> So it would be interesting to determine what kind of relocation you are seeing and where it came...