This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA


2013/8/8 Ilya Enkovich <enkovich.gnu@gmail.com>:
> 2013/8/8 Joseph S. Myers <joseph@codesourcery.com>:
>> On Fri, 2 Aug 2013, Ilya Enkovich wrote:
>>
>>> Hi All,
>>>
>>> I've updated MPX Wiki page
>>> (http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler).
>>> I added instrumentation description, programming model description,
>>> differences with other checkers, implementation details.
>>
>> Thanks.  As noted, there should be a clean separation between what's
>> generic and what's architecture-specific - the generic command-line
>> options, hooks etc. shouldn't mention "MPX" in their names.
>
> That is not a big issue to rename generic names. But I'm just still
> trying to choose proper names. I looked into -fbounds-check but its
> description already mention C/C++ and its semantics differs from what
> new instrumentation does. I consider using -fcheck=pointer (currently
> valid for Fortran) and 'chkp' instead of 'mpx' for generic things.
> Does it look OK?
I just realized that usage of option which is already defined for
other languages may be problematic when this option is passed to
MULTILIB_OPTIONS. So, probably, new common option -fcheck-pointers?

Thanks,
Ilya
>
>>
>> I'm unclear on the references to *_nobnd and *_nochk functions - are there
>> corresponding library (glibc etc.) changes to add additional function
>> variants?  Are all built-in functions that use pointers modified so that
>> GCC will insert the required checks when expanding inline?
> The idea was to add new versions of some functions into glibc and
> replace normal versions call with special versions call when possible
> (e.g. when we know memcpy call does not copy pointers). Currently in
> MPX mode expanding is allowed for _nochk_nobnd variant which is equal
> to regular call. I cannot be sure new version will be added into
> glibc. If not, we would probably create additional library in GCC.
>
>>
>> I'm also unclear on how much --enable-mpx does - in general, it's
>> desirable for a single compiler to be able to generate binaries both with
>> and without the checks, and so quite possibly to build libgcc, libstdc++
>> etc. as multilibs both with and without MPX, rather than needing to make a
>> static decision when GCC is built (so, any configure option should
>> preferably be about building *extra* library variants, for example, rather
>> than changing the options with which existing variants are built).
> Currently (in public mpx branch) --enable-mpx just adds compilation
> options to some libraries.
>
> I made an attempt to use multilibs instead. I tried to add mpx variant
> to target libraries build but got fail for libgfortran build. Does
> multilib support partial library rebuild? Actually I do not need
> libgfortran library (an many other libraries) to be in mpx version. Is
> it possible to get some libs from one place and some libs from another
> place?
>
> Thanks,
> Ilya
>
>>
>> --
>> Joseph S. Myers
>> joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]