Re: [RFC 9/9] x86/mm: Implement PR_SET/GET_TAGGED_ADDR_CTRL with LAM

2021-02-07 Thread Dmitry Vyukov via Gcc 
On Fri, Feb 5, 2021 at 4:43 PM H.J. Lu  wrote:
>
> On Fri, Feb 5, 2021 at 7:16 AM Kirill A. Shutemov
>  wrote:
> >
> > Provide prctl() interface to enabled LAM for user addresses. Depending
> > how many tag bits requested it may result in enabling LAM_U57 or
> > LAM_U48.
>
> I prefer the alternate kernel interface based on CET arch_prctl interface 
> which
> is implemented in glibc on users/intel/lam/master branch:
>
> https://gitlab.com/x86-glibc/glibc/-/tree/users/intel/lam/master
>
> and in GCC on users/intel/lam/master branch:
>
> https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master

Hi Kirill, H.J.,

I don't have strong preference for PR_SET/GET_TAGGED_ADDR_CTRL vs
ARCH_X86_FEATURE_1_ENABLE itself, but tying LAM to ELF and
GNU_PROPERTY in the second option looks strange. LAM can be used
outside of ELF/GNU, right?

GSoC

2021-02-07 Thread Ravi Kumar via Gcc 
Hello Sir,
I am Ravi Kumar. I am currently a 2nd year undergraduate(B.Tech) student. I 
want to participate in GSoC 2021 and want to work under the mentorship of GCC.  
  
WHY ME?
Because:
1.I have a proper knowledge and experience in C and C++ Language.
2. I have learnt to use git and GitHub.
3. I also have a theoretical knowledge of compilers and compiler organization.
4. I am ready to give 4-5 hours daily to the project.
5.I am familiar with GCC source code.

Since I am a new contributor and I have a little knowledge regarding this so I 
am facing lot of difficulties. But I am a good learner and I want to explore 
more in contribution and project completion under a mentor. Since I have the 
required skills for the project ideas that you have provided, I would love to 
work for it. 
Here is the project that I am opting:
Extend the static analysis pass



 


Sent from Mail for Windows 10

Re: [RFC 9/9] x86/mm: Implement PR_SET/GET_TAGGED_ADDR_CTRL with LAM

2021-02-07 Thread Kirill A. Shutemov 
On Sun, Feb 07, 2021 at 09:07:02AM +0100, Dmitry Vyukov wrote:
> On Fri, Feb 5, 2021 at 4:43 PM H.J. Lu  wrote:
> >
> > On Fri, Feb 5, 2021 at 7:16 AM Kirill A. Shutemov
> >  wrote:
> > >
> > > Provide prctl() interface to enabled LAM for user addresses. Depending
> > > how many tag bits requested it may result in enabling LAM_U57 or
> > > LAM_U48.
> >
> > I prefer the alternate kernel interface based on CET arch_prctl interface 
> > which
> > is implemented in glibc on users/intel/lam/master branch:
> >
> > https://gitlab.com/x86-glibc/glibc/-/tree/users/intel/lam/master
> >
> > and in GCC on users/intel/lam/master branch:
> >
> > https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master
> 
> Hi Kirill, H.J.,
> 
> I don't have strong preference for PR_SET/GET_TAGGED_ADDR_CTRL vs
> ARCH_X86_FEATURE_1_ENABLE itself, but tying LAM to ELF and
> GNU_PROPERTY in the second option looks strange. LAM can be used
> outside of ELF/GNU, right?

Sure. In both cases it's still a syscall.

-- 
 Kirill A. Shutemov

Re: [RFC 9/9] x86/mm: Implement PR_SET/GET_TAGGED_ADDR_CTRL with LAM

2021-02-07 Thread Dmitry Vyukov via Gcc 
On Sun, Feb 7, 2021 at 3:09 PM Kirill A. Shutemov  wrote:
>
> On Sun, Feb 07, 2021 at 09:07:02AM +0100, Dmitry Vyukov wrote:
> > On Fri, Feb 5, 2021 at 4:43 PM H.J. Lu  wrote:
> > >
> > > On Fri, Feb 5, 2021 at 7:16 AM Kirill A. Shutemov
> > >  wrote:
> > > >
> > > > Provide prctl() interface to enabled LAM for user addresses. Depending
> > > > how many tag bits requested it may result in enabling LAM_U57 or
> > > > LAM_U48.
> > >
> > > I prefer the alternate kernel interface based on CET arch_prctl interface 
> > > which
> > > is implemented in glibc on users/intel/lam/master branch:
> > >
> > > https://gitlab.com/x86-glibc/glibc/-/tree/users/intel/lam/master
> > >
> > > and in GCC on users/intel/lam/master branch:
> > >
> > > https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master
> >
> > Hi Kirill, H.J.,
> >
> > I don't have strong preference for PR_SET/GET_TAGGED_ADDR_CTRL vs
> > ARCH_X86_FEATURE_1_ENABLE itself, but tying LAM to ELF and
> > GNU_PROPERTY in the second option looks strange. LAM can be used
> > outside of ELF/GNU, right?
>
> Sure. In both cases it's still a syscall.

Oh, I meant just the naming scheme. The consts are declared in elf.h
and are prefixed with GNU_PROPERTY.

gcc-11-20210207 is now available

2021-02-07 Thread GCC Administrator via Gcc 
Snapshot gcc-11-20210207 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20210207/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 3d912941f29c27b2ac7c79b9e7cb2f1150e75758

You'll find:

 gcc-11-20210207.tar.xz   Complete GCC

  SHA256=bd1cca6b14cf66a0bfa2f9995672d482d1699da6d277d272c65503f0d7fc899f
  SHA1=c01ec2eda32bad04fbf8f7ffb7418d3f926e3238

Diffs from 11-20210131 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Calls to auto-vectorized AVX512 functions

2021-02-07 Thread Naoki Shibata via Gcc 



Hello,

I have a question as to the auto-vectorizer in GCC.

When AVX512 instruction is available, the auto-vectorizer in gcc 
sometimes generates calls to AVX2 functions instead of AVX512 functions.



$ cat vabitest.c
#include 
#include 

_Pragma ("omp declare simd simdlen(8) notinbranch") 
__attribute__((const)) double myfunc(double x);


#define N 1024
__attribute__ ((__aligned__(256))) double a[N], b[N], c[N];

int main(void) {
  for (int i = 0; i < N; i++) a[i] = myfunc(b[i]);
  for (int i = 0; i < N; i++) c[i] = sin(b[i]);
}

$ gcc-10 -ffast-math -O3 -mavx512f -fopenmp vabitest.c -S -o- | grep _ZGV
call_ZGVdN8v_myfunc@PLT
call_ZGVeN8v_sin@PLT


Is there a way to force gcc to generate calls to AVX512 function in 
cases like this?


Regards,

Naoki Shibata