search for: scandalous

On Mon, Aug 12, 2013 at 8:24 AM, Michele Scandale < michele.scandale at gmail.com> wrote: > On 08/12/2013 02:02 PM, Justin Holewinski wrote: > > On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale < > michele.scandale at gmail.com > > <mailto:michele.scandale at gmail.com>> wrote: > > > > On 08/12/2013 12:44 AM, Michele Scandale wrote: > >

On 08/12/2013 02:34 PM, Justin Holewinski wrote: > On Mon, Aug 12, 2013 at 8:24 AM, Michele Scandale <michele.scandale at gmail.com > <mailto:michele.scandale at gmail.com>> wrote: > > On 08/12/2013 02:02 PM, Justin Holewinski wrote: > > On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale > <michele.scandale at gmail.com <mailto:michele.scandale at

It's not clear to me how this would work for targets that use the same physical address space for multiple language-specific address spaces. If a target maps both constant and global to address space 42 (for example), how would the optimizer differentiate between these two? On Wed, Aug 7, 2013 at 7:15 PM, Michele Scandale <michele.scandale at gmail.com > wrote: > On 08/08/2013

On 08/08/2013 01:36 AM, Justin Holewinski wrote: > It's not clear to me how this would work for targets that use the same > physical address space for multiple language-specific address spaces. > If a target maps both constant and global to address space 42 (for > example), how would the optimizer differentiate between these two? > I think that the proposal of Pete would

On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale < michele.scandale at gmail.com> wrote: > On 08/12/2013 12:44 AM, Michele Scandale wrote: > > The idea is to extend the BasicAliasAnalysis to use addrspace modifier + > target > > information to decide aliasing based on physical address spaces and > create a > > "MemorySpaceAliasAnalysis" for those case

On Aug 12, 2013, at 6:52 AM, Michele Scandale <michele.scandale at gmail.com> wrote: > On 08/12/2013 02:34 PM, Justin Holewinski wrote: >> On Mon, Aug 12, 2013 at 8:24 AM, Michele Scandale <michele.scandale at gmail.com >> <mailto:michele.scandale at gmail.com>> wrote: >> >> On 08/12/2013 02:02 PM, Justin Holewinski wrote: >>> On Mon, Aug

On 08/12/2013 02:02 PM, Justin Holewinski wrote: > On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale <michele.scandale at gmail.com > <mailto:michele.scandale at gmail.com>> wrote: > > On 08/12/2013 12:44 AM, Michele Scandale wrote: > > The idea is to extend the BasicAliasAnalysis to use addrspace modifier + > target > > information to decide

On 08/08/2013 02:05 PM, Justin Holewinski wrote: > On Wed, Aug 7, 2013 at 9:52 PM, Pete Cooper <peter_cooper at apple.com > <mailto:peter_cooper at apple.com>> wrote: > > > On Aug 7, 2013, at 6:38 PM, Michele Scandale > <michele.scandale at gmail.com <mailto:michele.scandale at gmail.com>> wrote: > >> On 08/08/2013 03:16 AM, Pete

On Wed, Aug 7, 2013 at 7:45 PM, Michele Scandale <michele.scandale at gmail.com > wrote: > On 08/08/2013 01:36 AM, Justin Holewinski wrote: > >> It's not clear to me how this would work for targets that use the same >> physical address space for multiple language-specific address spaces. >> If a target maps both constant and global to address space 42 (for

On 08/07/2013 03:52 PM, Michele Scandale wrote: > > In the opencl specification is said that the four address spaces are > disjoint, so my conclusion of non aliasing with the others. In OpenCL 2.0, you can cast between the generic address space and global/local/private, so there's also that to consider.

On 08/11/2013 10:38 PM, Justin Holewinski wrote: > On Sun, Aug 11, 2013 at 5:49 AM, Michele Scandale <michele.scandale at gmail.com > <mailto:michele.scandale at gmail.com>> wrote: > > On 08/11/2013 08:41 AM, Micah Villmow wrote: > > How about this as a solution. > > > > Add one hook into TargetInstrInfo, and one into TargetISelLowering.

On Wed, Aug 7, 2013 at 9:52 PM, Pete Cooper <peter_cooper at apple.com> wrote: > > On Aug 7, 2013, at 6:38 PM, Michele Scandale <michele.scandale at gmail.com> > wrote: > > On 08/08/2013 03:16 AM, Pete Cooper wrote: > > > On Aug 7, 2013, at 5:12 PM, Michele Scandale <michele.scandale at gmail.com> > wrote: > > On 08/08/2013 02:02 AM, Justin

Dear all, I'm working on a late IR target dependent optimization on loops. A part of this optimization requires to derive "by hand" the trip-count expression of a given loop. In order to handle correctly these cases I need to check if the loop has an entry guard or not. The problem I have is that starting from the information I derive during my analysis (initial IV value, last IV

On Aug 7, 2013, at 6:38 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > On 08/08/2013 03:16 AM, Pete Cooper wrote: >> >> On Aug 7, 2013, at 5:12 PM, Michele Scandale <michele.scandale at gmail.com> wrote: >> >>> On 08/08/2013 02:02 AM, Justin Holewinski wrote: >>>> This worries me a bit. This would introduce language-specific

On Thu, Aug 8, 2013 at 12:49 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > On 08/08/2013 07:09 PM, Justin Holewinski wrote: >> >> I like having such a guarantee available, but I hesitate to *require* >> metadata in the IR. Perhaps if the metadata doesn't exist the verifier >> assumes the casts are valid and the optimizers have to assume all

Il 25/07/2012 10:07, Eli Friedman ha scritto: > On Wed, Jul 25, 2012 at 12:48 AM, Michele Scandale > <michele.scandale at gmail.com> wrote: >> Dear all, >> >> I'm working on an exploratory backend on llvm. In the instruction set I'm using >> I have an instruction (called DECJNZ) that decrements a register and, if the >> decremented value is not

On 08/08/2013 02:52 PM, Micah Villmow wrote: > This is something I proposed last year, so you might want to read up on that discussion first. > > You can find it here: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053277.html Uhm... I read the discussion, probably I've not understood the problem well: the conclusion (it has been committed?) is that to handle address

On Aug 7, 2013, at 5:12 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > On 08/08/2013 02:02 AM, Justin Holewinski wrote: >> This worries me a bit. This would introduce language-specific >> processing into SelectionDAG. OpenCL maps address spaces one way, other >> languages map them in other ways. Currently, it is the job of the >> front-end to map

On 08/08/2013 12:55 AM, Matt Arsenault wrote: > On 08/07/2013 03:52 PM, Michele Scandale wrote: >> >> In the opencl specification is said that the four address spaces are >> disjoint, so my conclusion of non aliasing with the others. > In OpenCL 2.0, you can cast between the generic address space and > global/local/private, so there's also that to consider. >

On 08/12/2013 12:44 AM, Michele Scandale wrote: > The idea is to extend the BasicAliasAnalysis to use addrspace modifier + target > information to decide aliasing based on physical address spaces and create a > "MemorySpaceAliasAnalysis" for those case where source language level > information may help, right? I was looking to the AliasAnalysis infrastructure and TBAA