On Wed, Aug 09, 2017 at 03:44:02PM -0700, Linus Torvalds wrote: > On Wed, Aug 9, 2017 at 3:06 PM, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: > > > > I have but I never posted it yet. > > Basically, I have specialized them: > > - TRUNC, ZEXT & SEXT: truncate (may be not neede), zero & sign extend > > for integers > > Makes sense. > > And yes, I think we could skip TRUNC (casting to a smaller type is one > of those questionable things we do now). > > Our IR doesn't really have any well-defined form for upper bits anyway > (ie there's no guarantee that values are zero-extended or > sign-extended to the full register width in the IR), so "TRUNC" > doesn't really have any sane semantics. > > > - PTRU & UPTR: conversion pointer from/to unsigned integer (not sure > > it's needed) > > So this is a separate thing that doesn't take a size? > > So a "int to ptr" conversion on a 64-bit architecture would be a > combination of SEXT.64 and a UPTR? > > If so, then yes, I think that's the right thing to do (and then in > basically all cases the PTRU/UPTR just goes away). > > Or, like TRUNC, just say that pointers simply *are* the same thing as > an integer of the same size, and PTRU/UPTR just doesn't exist at all. > > > - FCVTU & FCVTS: convert float to unsigned/signed integers > > - UCVTF & SCVTF: convert int to float > > - FCVTF: float to float convert (maybe even better/simpler with FTRUNC > > & FEXT ?à) > > > > The main objective being to make things more explicit a avoid to have > > to test the orig-type at each time. > > Yes. I think what you describe is the right thing to do. The current > casting is just wrong and nasty, and has too much implicit stuff. > > Linus I'm busy to test & polish the patch series corresponding to this and I discovered an annoying oddball: Cast to an union (where the union contains a field of the same type as the source). This is a GCC extension and unlike a normal cast it produces an l-value. The kernel uses this a few times (at least once as an l-value). It will need a bit work on sparse side to handle this. -- Luc -- 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
