[Llvm-bgq-discuss] bgclang r185769-20130706 on vesta/mira

Michael Kruse llvm-bgq-discuss at meinersbur.de
Wed Jul 17 10:33:17 CDT 2013


A small bugreport:

qpxintrin.h:658
#define vec_sldw(a, b, c) __builtin_shufflevector(a, b, c, (c)+1, (c)+2,
(c)+3);

The semicolon at the end should be removed. It prohibites using this macro
as a function argument.
(Why are some intrinsics defined as macros, but most as inline functions? I
think vec_sldw should be converted to an inlined function, because
otherwise c will be evaluated multiple times: vec_sldw(a, b, c++))

Kind regards,
Michael Kruse




2013/7/14 Hal Finkel <hfinkel at anl.gov>

> Erik,
>
> I've updated the installs on vesta/mira to fix this issue as well. First,
> the underlying problem was that structures that contain a vector4double a
> member need to have at least 32-byte alignment on the stack. LLVM had been
> getting this right for most things, but not when passing the structure *by
> value* to a callee (which requires a separate copy be made for use by the
> callee).
>
> Also, I'd like to make the following point (for everyone): Because of the
> way that the PowerPC ABI is defined, passing an aggregate, no matter how
> small or simple internally, is never exactly the same as passing raw data
> types. At best, it costs you some extra stack space. But...
>
> struct wrapper {
>   vector4double x;
> };
>
> foo(struct wrapper x) { ... }
> bar(vector4double y) { ... }
>
> When you call bar(y) then y should be passed directly in one of the QPX
> vector registers. When you call foo(x), then x is passed in a collection of
> 64-bit general-purpose registers (as are all aggregates), and/or on the
> stack (depending on how many other function parameters there are and in
> what order they appear). In C++, it is almost always better to pass by
> const reference (unless you really do need a copy to modify):
>
> foo(const wrapper &x) { ... }
>
> which should be just as easy for the compiler to inline, but is much more
> efficient if you end up with non-inlined calls.
>
>  -Hal
>
> P.S. For those with your own installs, there is a r185769-20130706-v3
> archive on http://trac.alcf.anl.gov/projects/llvm-bgq which includes this
> fix.
>
> ----- Original Message -----
> > On 2013-07-11, at 15:50 , Hal Finkel <hfinkel at anl.gov> wrote:
> >
> > > ----- Original Message -----
> > >> Hal
> > >>
> > >> Is this content of this archive installed on Vesta? If not, how do
> > >> I
> > >> use the content of this archive?
> > >
> > > Yes, it is installed on vesta (and mira). The archive is just for
> > > other people who have installs on their own.
> >
> >
> > Here is my next issue:
> >
> > The directory is ~eschnett/src/vecmathlib-qpx4, the source file is
> > test.cc. I build with
> >
> > /home/projects/llvm/bin/bgclang++
> > -I/soft/compilers/ibmcmp-may2013/xlmass/bg/7.3/include -o test
> > test.cc -L/soft/compilers/ibmcmp-may2013/xlmass/bg/7.3/bglib64
> > -lmass_simd
> >
>
> [snip]
>
> >
> > Current output is in the file 107701.output. This indicates that my
> > function any(boolvec)->bool encounters an error. It is here applied
> > to a boolean vector with all elements set to false, yet the function
> >
> >    bool any() const
> >     {
> >       return (*this)[0] || (*this)[1] || (*this)[2] || (*this)[3];
> >     }
> >
> > returns true.
> >
> > -erik
> >
> > --
> > Erik Schnetter <schnetter at cct.lsu.edu>
> > http://www.perimeterinstitute.ca/personal/eschnetter/
> >
> > My email is as private as my paper mail. I therefore support
> > encrypting
> > and signing email messages. Get my PGP key from
> > http://keys.gnupg.net.
> >
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> llvm-bgq-discuss mailing list
> llvm-bgq-discuss at lists.alcf.anl.gov
> https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alcf.anl.gov/pipermail/llvm-bgq-discuss/attachments/20130717/202414d7/attachment.html>


More information about the llvm-bgq-discuss mailing list