You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In official LLVMIR documentation , the alloca instruction has an optional align argument (at least in textural representation). When not specified, it is up to the target to choose a "convenient"
boundary for the type. llvmlite's alloca instruction doesn't have this argument and is always restricted to the target's alignment. This could leave some performance optimization on the table.
The text was updated successfully, but these errors were encountered:
I think this could also be a correctness issue if we're aiming to interoperate with code that requires particular alignment of structures - for example, IIRC complex values on CUDA are represented by a struct of 2 floats with an 8-byte alignment even when the natural alignment for that struct would be 4 bytes (I think @nvlcambier and I ran into this).
In official LLVMIR documentation , the
alloca
instruction has an optionalalign
argument (at least in textural representation). When not specified, it is up to the target to choose a "convenient"boundary for the type. llvmlite's alloca instruction doesn't have this argument and is always restricted to the target's alignment. This could leave some performance optimization on the table.
The text was updated successfully, but these errors were encountered: