similar to: [LLVMdev] Limit loop vectorizer to SSE

On 12 November 2013 15:14, Frank Winter <fwinter at jlab.org> wrote: > I am asking because the option 'force-vector-width' is too restrictive. > I would like to leave open the possibility to use vector width 2. I was about to say that, and you saved us both one cycle. ;) What you could do is to force an architecture that doesn't have AVX, only SSE. I'm not sure how

On 12 November 2013 15:53, Frank Winter <fwinter at jlab.org> wrote: > .. forcing the vector size to 4 does not prevent using AVX. > Sure. That's more for tests than anything else. So, there are ways of disabling stuf in Clang, for instance "-mattr=-avx" or "-target-feature -avx", but I'm not sure how you're doing it in the JIT. I'm also not sure

I am asking because the option 'force-vector-width' is too restrictive. I would like to leave open the possibility to use vector width 2. Frank On 12/11/13 10:05, Frank Winter wrote: > The AVX + JIT bug is hitting more frequently now. On a AVX machine the > loop vectorizer goes for a vector length of 8 for some of my functions > which in turn causes a SEGFAULT. > > Is

.. forcing the vector size to 4 does not prevent using AVX. I just hit the following: LV: We can vectorize this loop! LV: Found trip count: 4 LV: The Widest type: 64 bits. LV: The Widest register is: 256 bits. LV: Using user VF 4. Looks like I have to disable AVX somehow. (Which is sad on its own.) Frank On 12/11/13 10:34, Renato Golin wrote: > On 12 November 2013 15:14, Frank Winter

On 12 November 2013 16:05, Frank Winter <fwinter at jlab.org> wrote: > engineBuilder.setMCPU(llvm::sys::getHostCPUName()); > Try: engineBuilder.setMAttrs("-avx"); --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131112/4b00aed7/attachment.html>

On 15 November 2013 20:05, Frank Winter <fwinter at jlab.org> wrote: > Good catch! That was the problem in my case too. I totally > overlooked the alignment requirement for AVX. I wonder if the validation mechanism shouldn't have caught it earlier... Do you guys run validate on the modules before JIT-ing? --renato -------------- next part -------------- An HTML attachment was

On 12/11/13 11:01, Renato Golin wrote: > On 12 November 2013 15:53, Frank Winter <fwinter at jlab.org > <mailto:fwinter at jlab.org>> wrote: > > .. forcing the vector size to 4 does not prevent using AVX. > > > Sure. That's more for tests than anything else. > > So, there are ways of disabling stuf in Clang, for instance > "-mattr=-avx"

Hmm.. I don't quite understand. How can a module validator catch this, when it's the pointers, i.e. the payload, you pass as function arguments that need to be aligned.. ?! Frank On 15/11/13 15:16, Renato Golin wrote: > On 15 November 2013 20:05, Frank Winter <fwinter at jlab.org > <mailto:fwinter at jlab.org>> wrote: > > Good catch! That was the problem in my

I'm embarrassed to say my bug ended up being a user error. I was passing in pointers that were 16-byte aligned instead of 32. Explains why they worked fine for SSE but not AVX :) Sorry for the noise! -- View this message in context: http://llvm.1065342.n5.nabble.com/Limit-loop-vectorizer-to-SSE-tp63175p63419.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

Good catch! That was the problem in my case too. I totally overlooked the alignment requirement for AVX. Frank On 15/11/13 14:43, Josh Klontz wrote: > I'm embarrassed to say my bug ended up being a user error. I was passing in > pointers that were 16-byte aligned instead of 32. Explains why they worked > fine for SSE but not AVX :) Sorry for the noise! > > > > -- >

On 12 November 2013 21:10, Josh Klontz <josh.klontz at gmail.com> wrote: > Porting my project from JIT to MCJIT did not fix the code generation bug > Frank is also experiencing. However, Renato's "-avx" suggestion did resolve > the issue for me. Hopefully we can get some traction on this bug, happy to > help where possible! > Hi Josh, Frank, Glad to see you

My case is submitted. bug 17878 <http://llvm.org/bugs/show_bug.cgi?id=17878> In my case the segfault happens when calling the JIT'ed function. Thus some sort of 'payload' has to be created. Not sure if it's the same what Josh is hitting. Frank On 13/11/13 04:26, Renato Golin wrote: > On 12 November 2013 21:10, Josh Klontz <josh.klontz at gmail.com >

Frank, It sounds like the SLP vectorizer thinks that it is more profitable to use 128bit wide operations (because 256bit operations are double pumped on Sandybridge). Did you see a different result on Haswell? Thanks, Nadav > On Jul 1, 2015, at 11:06 AM, Frank Winter <fwinter at jlab.org> wrote: > > I realized that the function parameters had no alignment attributes on them.

Do you have a stack trace of the segfault? We have two different code emitters for X86 in LLVM. The one used by the normal compiler and MCJIT and the other used by the legacy JIT. All of the test cases for AVX support go through the first one so it gets the most attention. We try to keep the legacy JIT in sync with it, but have a history of failing at that. The stack trace of the segfault may

Is it possible that the AVX support in the JIT engine or x86-64 backend is not mature? I am getting segfaults when switching from a vector length 4 to 8 in my application. I isolated the barfing function and it still segfaults in the minimal setup: The IR attached implements the following simple function: void bar(int start, int end, int ignore , bool add , bool addme , float* out, float* in) {

Hi Frank, What does --debug-only=vectorize says? You may try to get the datalayout and the triple on the IR header, just to make sure you got everything right. LLVM will honour those, and front-ends should create them correctly. --renato On 1 July 2015 at 19:06, Frank Winter <fwinter at jlab.org> wrote: > I realized that the function parameters had no alignment attributes on them.

On 1 July 2015 at 21:22, Frank Winter <fwinter at jlab.org> wrote: > there were two follow-up emails. I only got one... weird... > The issue is solved. The SLP vectorizer has > a magic number built into the code which determines the max. vector length > to search for. That was set to 128 bits. Increasing it to 256 bits solved > the issue. That looks like a simple fix. Is

It's not much. (gdb) bt #0 0x00007ffff7f6506b in ?? () #1 0x000000000045d01a in main () at main.cc:165 Line 165 is the call to the function that was compiled by the JIT'er. Meaning that JIT'ing the function went well, but the code or the pointer are somehow corrupt. There is no particular reason why I am working with the legacy interface. Would you recommend to use the MCJIT

I added your suggestion and am using this now llvm::legacy::FunctionPassManager *functionPassManager = new llvm::legacy::FunctionPassManager(Mod); llvm::PassRegistry &registry = *llvm::PassRegistry::getPassRegistry(); initializeScalarOpts(registry); functionPassManager->add( new llvm::TargetLibraryInfoWrapperPass(llvm::TargetLibraryInfoImpl(targetMachine->getTargetTriple())) );

On 30 October 2013 18:40, Frank Winter <fwinter at jlab.org> wrote: > const std::uint64_t ir0 = (i+0)%4; // not working > I thought this would be the case when I saw the original expression. Maybe we need to teach module arithmetic to SCEV? --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: