similar to: [LLVMdev] Address space extension

On 08/07/2013 01:52 PM, Michele Scandale wrote: > > IMHO this information should be a plus that could be *safely* ignored > when not necessary and used where it can provide an improvement in > optimizations. This does not necessary mean the the middle-end (and > the back-ends) must be aware of the semantic of these logical address > spaces, it would be enough just to

On Aug 7, 2013, at 2:07 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 08/07/2013 01:52 PM, Michele Scandale wrote: >> >> IMHO this information should be a plus that could be *safely* ignored when not necessary and used where it can provide an improvement in optimizations. This does not necessary mean the the middle-end (and the back-ends) must be aware of the

On Aug 7, 2013, at 2:54 PM, Michele Scandale <michele.scandale at gmail.com> wrote: >> I don’t know if CUDA has aliasing address spaces, but that would also be >> useful to consider. Something simple like this might work. Note i’m >> using the examples from the clang discussion, that is "1 = opencl/cuda >> global, 2 = opencl_local/cuda_shared, 3 = opencl/cuda

Hi Michele, Are you considering nested address spaces? Apart from OpenCL, named address spaces have been proposed in scope of "Embedded C" draft N1275 (2007). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf --> Section 5.2: Named address spaces and named-register storage classes Summarizing, address spaces may overlap in a nested fashion. Typically their names are

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. > > 1) getAddressSpaceRelation(unsigned AS1, unsigned AS2) - Returns either disjoint, subset, superset, equal. Function defaults to equal. > 2) isAddressSpaceSupported(unsigned AS) - Returns true if supported, false otherwise.

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 Sun, Aug 11, 2013 at 5:49 AM, Michele Scandale < 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. > > > > 1) getAddressSpaceRelation(unsigned AS1, unsigned AS2) - Returns either > disjoint, subset, superset,

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 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.

+ the new llvm-dev On Fri, Aug 7, 2015 at 11:30 AM, Jingyue Wu <jingyue at google.com> wrote: > Hi folks, > > Unsurprisingly, leveraging the fact that certain address spaces don't > alias can significantly improve alias analysis precision and enhance > (observably 2x performance gain) load/store optimizations such as LICM and > DSE. > > This sounds to me an

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 Fri, Aug 7, 2015 at 12:01 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 08/07/2015 11:35 AM, Jingyue Wu wrote: > > + the new llvm-dev > > On Fri, Aug 7, 2015 at 11:30 AM, Jingyue Wu <jingyue at google.com> wrote: > >> Hi folks, >> >> Unsurprisingly, leveraging the fact that certain address spaces don't >> alias can

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 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/08/2013 12:24 AM, Pete Cooper wrote: > > On Aug 7, 2013, at 2:54 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > >>> I don’t know if CUDA has aliasing address spaces, but that would also be >>> useful to consider. Something simple like this might work. Note i’m >>> using the examples from the clang discussion, that is "1 =

> I don’t know if CUDA has aliasing address spaces, but that would also be > useful to consider. Something simple like this might work. Note i’m > using the examples from the clang discussion, that is "1 = opencl/cuda > global, 2 = opencl_local/cuda_shared, 3 = opencl/cuda constant" You are assuming that the target device has different physical address spaces (like, PTX

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

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 Aug 7, 2013, at 7:23 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > On 08/08/2013 03:52 AM, Pete Cooper wrote: >>> Why a backend should be responsible (meaning have knowledge) for a >>> mapping between high level address spaces and low level address spaces? >> Thats true. I’m thinking entirely from the persecutive of the backend >> doing

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