On Apr 24, 2014, at 0:30 , Jan Vesely <[email protected]> wrote:
> On Wed, 2014-04-23 at 19:49 +0200, Francisco Jerez wrote: >> Jan Vesely <[email protected]> writes: >> >>> On Tue, 2014-04-22 at 17:50 -0700, Matt Arsenault wrote: >>> <snip> >>> >>>>>> I think this is what v96:128 is for >>>>> according to [0], it specifies only alignment, not size. I could not >>>>> find an __attribute__ that would change size either. >>>>> >>>>> It should be possible to have ADMGPUDataLayout: public DataLayout class >>>>> that would intercept the call and fix the reported value, but I think it >>>>> would only move the hack to different place. >>>>> >>>>> I have added pocl-devel list as suggested. >>>>> >>>>> regards, >>>>> Jan >>>>> >>>>> [0]http://llvm.org/docs/LangRef.html#data-layout >>>>> >>>> >>>> Only the size in memory matters, which is what the required alignment >>>> specifies. DataLayout::getTypeAllocSize accounts for the alignment, but >>>> getTypeStoreSize does not. I actually thought this was half of what >>>> getTypeStoreSize was for, but it turns out it isn't. >>> >>> hm, I always thought that alignment only puts restrictions on starting >>> address and using padding was just a tool to do the job. >>> >>> anyway, thanks for the hint, using getTypeAllocSize works nicely. >>> since we are allocating space in the argument vector I think >>> getAllocSize is the right function to use. >>> >>> I'll post a patch. >>> >> >> I don't think that using getTypeAllocSize() instead of >> getTypeStoreSize() to calculate clover::argument::size would be a >> satisfactory solution. By doing that you'd redefine the API argument >> size exposed to the host for *all* argument types to be the >> device-dependent aligned size, which is definitely not what you want. > >> AFAIK 3-element vectors are an exception because they are the only types >> that are defined to have a different API size from their actual usable >> size, so they probably deserve special handling in invocation.cpp (as >> you did in your first patch). As the API size is target-independent I >> don't think that the fix belongs in Clang or LLVM, Clover is likely at >> fault. > > The way I understood the ch 6.1.5 is that both API and OpenCL C 3 > element vectors are required to be 4*sizeof(component). So a > sizeof(float3) == sizeof(cl_float3) == 16, and should be both host and > target independent. That's why clang (or more precisely libclc) looked > like a correct place. > > I understand that target device can have stricter alignment rules, but I > don't see how it can have different type sizes (my reading of the specs > is that these are binding for the target as well). OpenCL specifies the alignment of types; this is not up to the target. For the basic types, the alignment is their size. -erik -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform
_______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
