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). I can resend the original patch with debug output replaced by a comment. regards, Jan > > Thanks. > > > regards, > > Jan > > > > > > -- > > Jan Vesely <[email protected]> > > _______________________________________________ > > mesa-dev mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Jan Vesely <[email protected]>
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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
