This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA
- From: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Uros Bizjak <ubizjak at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, Areg Melik-Adamyan <areg dot melikadamyan at gmail dot com>
- Date: Thu, 8 Aug 2013 16:32:20 +0400
- Subject: Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA
- References: <CAMbmDYZdrR8t66VtNPFxbz33mMX0M-tMj_Bv=uvrejui_YnVWg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1307242237420 dot 5307 at digraph dot polyomino dot org dot uk> <CAMbmDYbNvPh8MiJkgx29Hc+d_czzLeFuxeG4uDz_AozqX3j1cg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1307251415290 dot 18813 at digraph dot polyomino dot org dot uk> <CAMbmDYamg+jwEY6FiZ_+_DT8nqug58Gi5Nf2PSDZ26Bi17K5=A at mail dot gmail dot com> <CAMbmDYYM5Qfayx2yoFyZ4oKUhOi8aD=jWCNMyzEMadSYYC2fqA at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1308072202290 dot 26185 at digraph dot polyomino dot org dot uk> <CAMbmDYZLgu7XAQfOQkUAmKE1aBt0mwJpr8TWPRbWeKZAZ2S4Dg at mail dot gmail dot com>
2013/8/8 Ilya Enkovich <email@example.com>:
> 2013/8/8 Joseph S. Myers <firstname.lastname@example.org>:
>> On Fri, 2 Aug 2013, Ilya Enkovich wrote:
>>> Hi All,
>>> I've updated MPX Wiki page
>>> 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?
>> 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
>> Joseph S. Myers