Re: [PATCH, i386, MPX, 1/X] Support of Intel MPX ISA. 1/2 Bound type and modes

[Ilya Enkovich <enkovich dot gnu at gmail dot com>]

2013/10/21 Jeff Law <law@redhat.com>:
> On 10/15/13 07:31, Ilya Enkovich wrote:
>>
>> Hey guys,
>>
>> could please someone look at this small patch? It blocks approved MPX
>> ISA support on i386 target.
>
>
>>>>
>>>> diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
>>>> index 1d62223..02b1214 100644
>>>> --- a/gcc/doc/rtl.texi
>>>> +++ b/gcc/doc/rtl.texi
>>>> @@ -1382,6 +1382,10 @@ any @code{CC_MODE} modes listed in the
>>>> @file{@var{machine}-modes.def}.
>>>>   @xref{Jump Patterns},
>>>>   also see @ref{Condition Code}.
>>>>
>>>> +@findex MODE_BOUND
>>>> +@item MODE_BOUND
>>>> +Bound modes class.  Used to represent values of pointer bounds.
>>>> +
>>>>   @findex MODE_RANDOM
>>>>   @item MODE_RANDOM
>>>>   This is a catchall mode class for modes which don't fit into the above
>
> So why are bounds distinct modes?    Is there some inherent reason why
> bounds are something other than an integer mode (MODE_INT)?
>
> Similarly what's the rationale behind having new types for bounds?  Is there
> some reason why they couldn't be implemented with one of the existing types?
>
> ISTM the entire patch is gated on being able to answer those two questions.
>

Hello Jeff,

Before introducing new type and mode we tried to implement everything
using existing ones. We tried integers, pointers, complex with pointer
type as base and also structure of two pointers. The problem is that
semantics of bounds is different from everything we have for base
types. All operators (exprs) we have for existing types are not
applicable to bounds. We probably may use some existing type/mode but
it would still require some additional flag to mark bounds. And almost
each first time we handle chosen basic type, it would be required to
check if we are working with bounds. I do not think many GCC
developers (at least in the nearest future) will care about
instrumented code while writing their patches. It means that many
developers may break instrumented code by adding any sort of
manipulation with values of type/mode we choose as basic for bounds.
I'm sure having a proper type is much more convenient and natural.

In addition to all said for bound type, bound mode may also have
different binary format. On i386 target bounds have special binary
format, it is not equal to pair of pointers. In many places (ABI, insn
templates etc.) we need to know if we work with bounds. E. g. passing
'long long' and bounds on a register(s) is different even if size is
the same.

Shortly: why to use same base type/mode for totally different matters?
I do not know if it is possible to implement everything using existing
types and modes. Probably it is possible, but for me it does not seem
a right way to go.

Thanks,
Ilya

>
> jeff
>