similar to: [cfe-dev] Disabling vectorisation at '-O3'

No, I’m wrong. I think that bug is actually in ‘hasFlag’ itself. In ‘llvm/lib/Option/ArgList.cpp’ line #70: bool ArgList::hasFlag(OptSpecifier Pos, OptSpecifier PosAlias, OptSpecifier Neg, bool Default) const { if (Arg *A = getLastArg(Pos, PosAlias, Neg)) return A->getOption().matches(Pos) || A->getOption().matches(PosAlias); return

Please ignore this thread - I got myself confused, the code is fine - too many long days and nights staring at code. There is an issue, but it is different to what I thought. My command line is not: clang -S -O3 -fno-vectorize -fno-slp-vectorize foo.c but: clang -S -fno-vectorize -fno-slp-vectorize -O3 foo.c The difference was subtly hidden in a much longer argument list

Hi Martin, On Fri, 3 Aug 2018 at 14:10, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > $ git branch --list > * master > martino By default "git branch" only lists local branches. "git branch -a" will list all of them, including (for me) "remotes/origin/release_70". If you just type "git checkout release_70" git will

Thanks Tim, Sometimes my hacks last longer than I want as it isn't always apparent how I can implement it properly. At the moment I am looking at changes I need to 'MachineBasicBlock::ReplaceUsesOfBlockWith'. It is most likely that I need to handle the issue in a different way, but the change I need works here for my target for the time being, but breaks X86 which I also build for

There's always the hypothetical template<typename T> llvm::Triple giveMeATripleDamnYou(const T &); Just keep adding implementations until you stop needing to. ;-) Cheers. Tim. On 1 January 2018 at 17:00, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Thanks Tim, > > Sometimes my hacks last longer than I want as it isn't always apparent how I can

Hi David, When I use CMake to configure, ‘zlib’ and its header are detected - I build on CentOS 6.5 or CentOS 7. Since I run CMake from the command-line, I tried added ‘-DLLVM_ENABLE_ZLIB=0’ and ‘-DLLVM_ENABLE_ZLIB=1’ (using ‘-DLLVM_ENABLE_ZLIB=ON’ does not seem to work). Both ‘clang’ and ‘llvm-profdata’ (and all other tools and utilities) are configured and built together, in any event,

Hi Martin, On 25 September 2017 at 20:35, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Are you building a Debug or Release version of the compiler? It seems that in Release builds of LLVM 5.0 the dump() implementation is absent, although the method is available in the interface. This is plain wrong in my view. If the dump() has to be removed then it should not be present

We discovered what is happening. SDAGCombiner essentially looks at various combinations of nodes to do with vectors, and when it can, it creates a vector shuffle. The problem is, that our vector shuffle lowering builds new trees with vector element, or vector sub-vector insert sequences. The generic DAGCombiner, reconstructs these into a new shuffle, and so the loop continues - we reduce it,

We'll be doing something similar for our OpenVMS port.  Right now I'm using "AsmStreamer->GetCommentOS()" and writing to the stream at the assembler level but that gets aligned on a right-side column (the column is hardcoded) and you have to be in verbose mode.  So if you come up with something or have a quick design, post it so perhaps we can leverage each other's work. 

> On Jan 16, 2018, at 11:31 PM, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > > Thanks Matthias, > > I have both a pre-RA and a post-RA scheduler, and I had thought that I could track “has RA happened?” by setting a flag in my pre-RA scheduler as it completes - my suspicion (which you have confirmed) was that “#vregs == 0” was not a safe assumption. What I

Yes, if it is in the interface it would make more sense to have a null implementation at the very least. In my out-of-tree target, I also removed them from the interface if the build was for Release to ensure that I got compile-time errors to reveal other places I might have otherwise missed. All the best, MartinO -----Original Message----- From: Dibyendu Majumdar [mailto:mobile at

Martin: It sounds like you are doing is more akin to shuffle selection than fusion and therefore it's a better fit for instruction selection than DAGCombining. Try movign it to <Target>ISelDAGToDAG's Select (or potentially PreprocessISelDAG). Th -Nirav On Tue, Mar 6, 2018 at 4:05 PM Martin J. O'Riordan <MartinO at theheart.ie> wrote: > We discovered what is

set LLVM_ENABLE_ZLIB=ON with cmake invocation. zlib should be installed and zlib.h header file needs to be in the header search path. Is your llvm-profdata tool built together with clang? David On Tue, Jul 18, 2017 at 1:04 PM, Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org> wrote: > How can I build the profile reader with ZLIB support enabled? I configure > and

Thanks very much Eric for taking the time to carefully explain this to me. So if I am the author of the backend for a new processor technology, or willing to modernise my existing implementation, you would recommend that the ‘-mcpu’ option is deprecated and probably best not used at all, or perhaps just as a synonym for ‘-march + -mtune’? The first part of the target triple guides the

Sorry, my reply “to all” left out LLVM-Dev From: Martin J. O'Riordan [mailto:MartinO at theheart.ie] Sent: 04 April 2018 16:41 To: 'David Blaikie' <dblaikie at gmail.com>; 'mcrosier at codeaurora.org' <mcrosier at codeaurora.org>; 'Chandler Carruth' <chandlerc at gmail.com>; 'Eric Christopher' <echristo at gmail.com> Subject: RE:

Hi Martin On 25 September 2017 at 21:13, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Yes, if it is in the interface it would make more sense to have a null implementation at the very least. In my out-of-tree target, I also removed them from the interface if the build was for Release to ensure that I got compile-time errors to reveal other places I might have otherwise

Hi LLVM-Devs, I am in the process of updating our out-of-tree implementation from v5.0 to v6.0 RC3, and while it builds and mostly runs, I am having trouble with a small number of tests where the 'WorklistMap' in 'DAGCombiner::Run' never becomes empty. This is resulting in a runaway state of continuous heap allocation until the process exhausts all system memory. But I can't

Cool this is better than I expected - I never thought about the YAML support. And the document reference is really very good. Thanks Francis, MartinO -----Original Message----- From: Francis Visoiu Mistrih [mailto:francisvm at yahoo.com] Sent: 05 February 2018 21:43 To: Martin J. O'Riordan <MartinO at theheart.ie> Cc: LLVM Developers <llvm-dev at lists.llvm.org>; Adam Nemet

Martin: I suspect this is an issue with post-DAG legalization store merging in the DAGCombiner. If you have a custom lowered type the DAGCombiner may end up merging a set of stores and immediately splitting them up in legalization. You should be able to disable this pass universally by overriding mergeStoresAfterLegalization() or conditionally for cases that shouldn't match with

On Fri, 3 Aug 2018 at 11:42, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > A few months ago I switched from using SVN for the LLVM project to using the GIT mono-repo, but I am still not particularly good at using GIT. How can I use the GIT command-line interface to select to the exact same set of sources used for the v7.0.0 branch, Do you mean the commit