similar to: '-fsave-optimization-record' and VS2015 built compiler

Hi LLVM-Devs, The LLVM 'cl::opt' templates are really useful, and provide a lot of flexibility. But I don't see any support for ranged options. What I would like is to have an option which is an integer type, and to restrict the set of values provided to a simple upper and lower bound, for example between 10 and 2000. Is there a way of expressing this with the 'cl::opt'

Hi LLVM-Devs, I am considering switching to using 'llvm-lld' instead of Gnu 'ld' in a future revision of our out-of-tree target, and I am wondering is there a getting started guide for how to go about extending 'llvm-lld' to support an additional target. Thanks, MartinO -------------------------------------------------------------- Intel Research and Development

With LLVM v5.0, I found failures in some of the 'gcc.c-torture/execute' tests due to a change in the optimisation where undefined behaviour is involved. The tests that fail are the '20040409-[123].c' tests. The underlying failure is due to the optimisation of the following: int test2(int x) { return x + INT_MIN; } from using an ADD instruction to using an OR instruction.

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

Yes, the hairy-edges of undefined behaviour - UB is UB. It does mean that given: __attribute__((noinline)) int foo(int a, int b) { return a + b; } int bar1(int x) { return foo(x, INT_MIN); } int bar2(int x) { return x + INT_MIN; } 'bar1' and 'bar2' have different outcomes. However, I think that the new optimisation is neat and valid and I am not suggesting that it should

We are trying to get PGO working for our embedded out-of-tree target, but the utility 'llvm-profdata' does not like the data we are giving it. Because this is not a hosted environment, we have to off-chip the profiling data ourselves, and although the data looks okay, 'llvm-profdata' reports the following error: llvm-profdata show -all-functions -counts -detailed-summary -text

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,

I am trying to support an experimental DSL that uses non-C identifiers, but I want to write the implementation of the runtime support libraries for this DSL in C. The compiler is built using the LLVM v5.0.0 release branch. To do this I thought I could simply write: int foo() { return 42; } // The C implementation asm(".alias nonCname foo"); // Make the non-C name be a synonym for

Can we improve the error message here? We should be able to check zlib::isAvailable and give an error like "profile uses zlib compression but the profile reader was built without zlib support" or so in this case. Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> writes: > The __llvm_prf_names section is compressed but your llvm-profdata tool is > probably not built

I'm not aware of a written guide either. In 2016 I did a talk on that subject at the LLVM Cauldron (http://llvm.org/devmtg/2016-09/#schedule) although quite a bit has changed since then so I'm hesitant to recommend it apart from general principles. I can't speak for the COFF side as I've only worked on the ELF side of LLD; my suggestions on where to start: - Properties of the

Hi everyone, I run some functions using ORC JIT, now I need to add custom instrumentation. I want to add two callbacks to each function: ‘enterFunction' at the beginning and ‘leaveFunction' at the end. Intuition says that I could ‘just' insert CallInst's to the first and the last basic blocks in the function. Am I correct? Are there any other/better way to do this? Is there

Quick question. The 'ISD::CTPOP' node allows a target to lower the counting of ones in a word to a single instruction. Our target also has an instruction for counting the zeroes in a word. Does CTPOP support counting of zeroes as well as ones instead of doing either "CTPOP(INVERT(operand))" or "N-bits - CTPOP(operand)"? Thanks, MartinO

Hi Sanjoy, Yes these are C tests (from 'gcc.c-torture/execute'), and as I indicated in my original message, the tests are not valid because the behaviour is undefined. However, it was while investigating these new failures in these tests that I realised that this optimisation existed. The optimisation itself is perfectly valid, but it does mean that integer underflow will no longer be

Thanks for the hint, I didn’t know about this option. That’s a great reference! However, I am trying to be a compiler/language agnostic. Also (for whatever reasons) I need a numeric ID of a function rather then its address. So the question is still opened. May I assume that the following always holds: The first basic block in a function is an entry point and the last basic block in a function is

On Mon, Jun 26, 2017 at 5:04 AM, ORiordan, Martin <martin.oriordan at intel.com > wrote: > Thanks Sean and Silva. > > > > I guess what I was seeking was a URL that I could point (non-compiler) > people at, but I guess no such reference exists. What I can do if > reference bot the source manager and use ‘-mllvm -debug-pass=Structure’ > for each optimisation level,

On 1/18/2018 12:57 AM, ORiordan, Martin via llvm-dev wrote: > Quick question. The 'ISD::CTPOP' node allows a target to lower the counting of ones in a word to a single instruction. Our target also has an instruction for counting the zeroes in a word. Does CTPOP support counting of zeroes as well as ones instead of doing either "CTPOP(INVERT(operand))" or "N-bits -

On 25 January 2018 at 15:38, ORiordan, Martin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi LLVM-Devs, > > I am considering switching to using 'llvm-lld' instead of Gnu 'ld' in a future revision of our out-of-tree target, and I am wondering is there a getting started guide for how to go about extending 'llvm-lld' to support an additional target. I

I agree, it's much clearer, it just takes runs at multiple opt levels and therefore I don't find it to be a "one stop shop". On Jun 24, 2017 8:44 PM, "Sean Silva" <chisophugis at gmail.com> wrote: > Looking at PassManagerBuilder can be useful because there are sometimes > comments giving some idea of the intent of the particular choice of passes, > but

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

On 21 August 2017 at 11:53, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > One thing to be aware of with this is that (IIRC) tablegen uses the pattern to infer things about the pattern. One example I vaguely remember is that an empty pattern would result in the same effect as hasSideEffects=1 and I think there were others. Thanks for the note - excellent point. Looking at