PR16752[PATCH]: 'mode' attribute for unusual targets doesn't work properly.
Stepan Dyatkovskiy
stpworld at narod.ru
Tue Sep 3 02:16:18 PDT 2013
Hi Eli,
Sorry for latency.
As you remember this patch should correct 'mode' attr implementation.
You proposed to use generic way of type detection for each target: just
scan for target types and select one with suitable width.
Unfortunately I can't commit patch with generic implementation. I got
test failure for clang. And I expect more failures for another targets.
The reason is next.
The target could still keep mode unsupported even if it has type of
suitable width. I mean the next.
For example this string should cause error for i686 machines (128 bit
float):
typedef float f128ibm __attribute__ ((mode (TF)));
But in case of generic approach for all targets it would be passed.
In this case virtual functions allows to implement exceptions.
In this case 'getIntTypeByWidth' may be a bit confusing name. Instead it
is supposed to return type for some particular mode, not by width.
Something like getInt/RealTypeForMode(width, sign).
Though, currently I kept the original name.
-Stepan.
Eli Friedman wrote:
> On Sun, Aug 25, 2013 at 9:34 AM, Stepan Dyatkovskiy <stpworld at narod.ru
> <mailto:stpworld at narod.ru>> wrote:
>
> Hi Eli,
> Thanks for review!
>
>
> >
>
> enum RealType {
> + NoFloat = 255,
> Float = 0,
> Double,
> - LongDouble
> + LongDouble,
> };
>
> Unless I'm missing something, there isn't any reason not to make
> NoFloat 0.
>
> Yes, there is. Since there types could be encoded, and Float is
> supposed to be encoded as 0. It couses several crashes:
> Clang :: CodeGenObjC/fpret.m
> Clang :: CodeGenObjC/metadata-symbols-__64.m
> Clang :: Sema/attr-mode.c
>
> Oh, okay, that's fine.
>
>
>
> + /// \brief Return integer type with specified width.
> + virtual IntType getIntTypeByWidth(unsigned BitWidth, bool
> IsSigned) const;
> +
> + /// \brief Return floating point type with specified width.
> + virtual RealType getRealTypeByWidth(unsigned BitWidth) const;
>
> Instead of making these virtual, would it be possible to make these
> figure out the appropriate types based on the widths etc. we already
> compute? e.g. for the integer types, something like so:
>
> TargetInfo::IntType TargetInfo::getIntTypeByWidth(
> unsigned BitWidth, bool IsSigned) const {
> if (getCharWidth() == BitWidth)
> return IsSigned ? SignedChar : UnsignedChar;
> if (getShortWidth() == BitWidth)
> return IsSigned ? SignedShort : UnsignedShort;
> if (getIntWidth() == BitWidth)
> return IsSigned ? SignedInt : UnsignedInt;
> if (getLongWidth() == BitWidth)
> return IsSigned ? SignedLong : UnsignedLong;
> if (getLongLongWidth() == BitWidth)
> return IsSigned ? SignedLongLong : UnsignedLongLong;
> return NoInt;
> }
>
> I'd prefer to make things as simple as possible for people
> adding new targets.
>
> OK. I did it. The reason was to keep current implementation but in
> better form, so everybody could customize it. Implementation you
> proposed could work differently, though I can watch for buildbots
> after commit and reject it if something went wrong.
>
>
> Sorry it took a little while to get to reviewing this.
>
> Sorry me to. I was on vocation :-)
>
>
> - LongDouble
> + LongDouble,
> };
>
> I don't recall whether all the compilers we care about accept this
> without complaining; please leave out the extra comma.
>
> Otherwise, LGTM.
>
> -Eli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ModeAttr-2013-09-03.patch
Type: text/x-diff
Size: 10908 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130903/43da45bc/attachment.patch>
More information about the cfe-commits
mailing list