Re: [PATCH] fix casts when linearizing compound assignments
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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
[Newbies FAQ] [Kernel List] [Site Home] [IETF Annouce] [DCCP] [Netdev] [Networking] [Security] [Bugtraq] [Photo] [Yosemite] [MIPS Linux] [ARM Linux] [Linux Security] [Linux RAID] [Linux SCSI] [DDR & Rambus] [Trinity Fuzzer Tool]