On Thu, Aug 10, 2017 at 12:44 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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). Maybe it can be useful for a short time after linearization, if we do some type analysis or so, I'm not sure. But after a while, they must be simplified away or converted to an AND mask. > 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? Yes, it's the idea. Basically a no-op. > 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. Same as for TRUNC, I think. At the end it's sure we don't want them, they are just the same as unsigned integers of the same size. But maybe during early phases, we want to keep them as such because we need to know they correspond to a pointer or an address. >> - 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. Yes, the missing of an explicit information about the signed/unsigned is quite error-prone. -- 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
