On 06/08/2012 03:10 PM, Pekka Enberg wrote:
So it seems that LLVM really wants to use the "getelementptr" thingy
for these. I have no idea what makes the most sense from sparse IR
point of view.
IMO it's a major backend design choice, GEP or not.
Either choice requires a bit of ugly work, in different places. sparse
already calculates sufficient information to create low-level
address/offset load/store generated code. LLVM API seems to "prefer"
that one use GEP code and associated type information, and was written
with this preference in mind. HOWEVER it is not a hard requirement, and
addr/ofs load/store lowlevel code can be generated. You wind up
abandoning LLVM's type-related APIs, with all that entails.
Using GEP with sparse, OTOH, enables smarter warnings, optimizations,
aliasing behaviors etc. during code generation, by virtue of providing
more type information throughout the LLVM compile process. The hard
work of GEP+sparse is that sparse in places prefers to linearize to a
lower level, and you may wind up having to re-create (or store early)
some advanced type information sparse deems unimportant in later
linearization phases.
I am biased in favor of GEP (more information) but sparse at present is
biased in favor of addr/ofs load/store. Each has benefits and costs.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
