[cfe-users] floor is vectorized, but not sin, cos or exp

[Klaus Leppkes via cfe-users]

Hi,

according to the doc 
(https://releases.llvm.org/7.0.0/docs/Vectorizers.html) floor, sin, cos 
should be vectorized.


I can confirm (using the great https://gcc.godbolt.org/ tool) that using 
the flags "-Ofast -mavx2  -fopenmp -ffast-math" the right avx2 opcode 
(vroundps) is emited for floor (in foo), but unfortunately not for sin, 
cos or exp (e.g. see sin in bar below).


GCC 8.1+ and the Intel Compiler icc 13+ insert call to vectorized 
implementations (_ZGVbN4v_sinf or __svml_sinf4 ), but clang seems to 
have nothing like this.


Here is my small testcode:

#include

voidfoo(float* __restrict__attribute((aligned(32))) x
, float* __restrict__attribute((aligned(32))) y) {
for(inti = 0; i < 4; ++i)
y[i] = floor(x[i]);
}


voidbar(float* __restrict__attribute((aligned(32))) x
, float* __restrict__attribute((aligned(32))) y) {
for(inti = 0; i < 4; ++i)
y[i] = sin(x[i]);
}

I have reproduced this behavior on different machines. Maybe I am doing 
s.th. wrong here, but it seems like there is no vectorized 
implementation for sin, cos etc. I am using h2lib for now 
(http://h2lib.org/doc/d1/d89/simd__avx_8h_source.html) as a workaround, 
but I expect clang to do this job.


Can anybody comment on this please?

Cheers
Klaus
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

[cfe-users] Fwd: floor is vectorized, but not sin, cos or exp

[Jonas Toth via cfe-users]

I am forwarding this to cfe-dev as it might this sounds like a bug and
cfe-users is not read that much.



 Weitergeleitete Nachricht 
Betreff:[cfe-users] floor is vectorized, but not sin, cos or exp
Datum:  Tue, 11 Dec 2018 16:47:16 +0100
Von:Klaus Leppkes via cfe-users 
Antwort an: Klaus Leppkes 
An: cfe-users@lists.llvm.org



Hi,

according to the doc
(https://releases.llvm.org/7.0.0/docs/Vectorizers.html) floor, sin, cos
should be vectorized.

I can confirm (using the great https://gcc.godbolt.org/ tool) that using
the flags "-Ofast -mavx2  -fopenmp -ffast-math" the right avx2 opcode
(vroundps) is emited for floor (in foo), but unfortunately not for sin,
cos or exp (e.g. see sin in bar below).

GCC 8.1+ and the Intel Compiler icc 13+ insert call to vectorized
implementations (_ZGVbN4v_sinf or __svml_sinf4 ), but clang seems to
have nothing like this.

Here is my small testcode:

#include

voidfoo(float* __restrict__attribute((aligned(32))) x
, float* __restrict__attribute((aligned(32))) y) {
for(inti = 0; i < 4; ++i)
y[i] = floor(x[i]);
}


voidbar(float* __restrict__attribute((aligned(32))) x
, float* __restrict__attribute((aligned(32))) y) {
for(inti = 0; i < 4; ++i)
y[i] = sin(x[i]);
}

I have reproduced this behavior on different machines. Maybe I am doing
s.th. wrong here, but it seems like there is no vectorized
implementation for sin, cos etc. I am using h2lib for now
(http://h2lib.org/doc/d1/d89/simd__avx_8h_source.html) as a workaround,
but I expect clang to do this job.

Can anybody comment on this please?

Cheers
Klaus
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] [run-clang-tidy] new replacement overlaps with an existing replacement

[Mateusz Loskot via cfe-users]

On Mon, 10 Dec 2018 at 22:25, Jonas Toth  wrote:
> Am 10.12.18 um 22:14 schrieb Mateusz Loskot via cfe-users:
> >
> > Why clang-tidy tries to re-fix the typedef with new replacement
> > instead of keeping the existing one, the generic one?
>
> Maybe a bug that does not handle some possible cases well. I know, that
> `use-using` has its problems sometimes.

Hi Jonas,

I think I may be hitting some of the cases or my configuration of TU-s
is not optimal for clang-tidy refactoring.

For instance, I observed that overlapping replacements issue
while running run clang-tidy against generated .cpp files
aiming to test Boost.GIL headers are self-contained.

That is, for each X header in Boost.GIL headers, there is .cpp file

#include 
int main() {}

Plus, there are also .cpp files with regular (unit) tests, with
specific specialisations of templates, etc.

> > i.e. using type = detail::file_stream_device
> >
> > I've tried to prepare a minimal example, but I couldn't reproduce this 
> > issue.
>
> Do you know which `TU` triggered the behaviour? If you find it out you
> can fully preprocess the file and check if the behaviour is still present.
> Then you can `creduce` the issue or create a bug-report and we reduce it

I tried to identify such TU-s, but all my attempts did not reproduce
the problem.
I chose candidates from .cpp files that occur in clang-tidy log
immediately before
overlapping replacements reported in the original error.

For example, these two replacements from
- bmp_read_test.cpp file listed before using type =
detail::file_stream_device
- jpeg_read_test.cpp file listed before using type =
detail::file_stream_device

I preprocessed those files with g++ -E into
bmp_read_test.i.cpp
jpeg_read_test.i.cpp
Then, modified compile_commands.json to run clang-tidy against those
*.i.cpp files.

This seems to work fine,I see typedef replaced as expected

using type = detail::file_stream_device;

That seems to confirm no bug in clang-tidy, but the issue is specific
to my setup.

> > I observed, that if I manually prepare compile_database.json with
> > single .cpp file that just `#include `,
> > that is the header with definition of the base templates
> > and no definitions with higher level specialisations for format tags
> > are included,
> > then clang-tidy applies the expected fixes without any warnings.
> >
> > Could anyone share any insights about this issue?
>
> What can happen (especially template-heavy code) that multiple
> inclusions of a file (as always happening) results in different fixes
> for the same code-location.
>
> `run-clang-tidy` does the replacements at the end. That means if
> multiple TUs will result in different fixes there will be collisions and
> it is not resolveable which one is correct.

I suspect that is the case indeed.

I have created new test in GIL which generates single .cpp file
that includes all headers (https://github.com/boostorg/gil/pull/184):
I generated compile_commands.json and manually removed all commands
but the one with .cpp including all headers.
Finally, I run clang-tidy against it, I get no warning about overlapping
replacements and all typedef-s are replaced with correct using declaration.

I think think that is the optimal workflow for the header-only Boost.GIL libary.

Thanks for help!

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users