similar to: Any update on the v4.0 release dates

Thanks :) From: 陳韋任 [mailto:chenwj.cs97g at g2.nctu.edu.tw] Sent: 14 April 2017 12:53 To: Martin J. O'Riordan <martin.oriordan at movidius.com> Cc: LLVM Developers <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Options for timing passes in LLVM? Refer to `llc` document [1], it would be `--time-passes`. [1] http://llvm.org/docs/CommandGuide/llc.html HTH,

I am trying to upgrade to the LLVM v4.0 branch, but I am seeing failures in my TableGen descriptions for conversion from FP32 to FP16 (scalar and vector). The patterns I have are along the lines of: [(set (f16 RF16:$dst), (fround (f32 RF32:$src)))] or: [(set (v2f16 VF16:$dst), (fround (v2f32 VF32:$src)))] and these now produce the errors: error: In CONV_f32_f16: Type inference

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,

Hi LLVM-Dev, Are there any options that can be used to report the time each LLVM pass takes to execute? I am examining a program that now takes about 6 times longer to compiler since we moved to the v4.0 sources from the v3.9 sources (~54s to ~320s), and so far my investigation does not seem to point to our additional target specific passes, so I would like to see where the time is being

In order to implement a subtle memory access optimisation during post-RA scheduling, I want to be able to determine some properties about the memory access. If I have two registers referring to memory, how can I determine if they are derived from the same base-pointer? Often LLVM will optimise to use intermediate registers holding partial displacements, for example, when a 'struct'

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>,

Thanks Ahmed and also Alex for your replies. This is more or less what I was realising, but it is a great confidence booster to know that it is the correct way also. I can replace all of my various 'Select*' specialisations with version that use 'ReplaceNode/SelectCode' and return 'void', but what about the places where I currently call 'Select(N)' directly?

Thanks again for your help Steve, I’m thinking perhaps my “SelectADDRrr” pattern is inadequate. The sign-extension is at the hardware level, the code generator sees (should see) it as a 16-bit signed register value. My implementation is just: bool SHAVEISelDAGtoDAG::SelectADDRrr(SDValue &Addr, SDValue &Base, SDValue &Offset) { if ((Addr.getOpcode() == ISD::ADD) { Base

Thanks for the quick answer Bruce. So far as I can tell (from a quick read), this is really for integrated assemblers/disassemblers - but we use an external assembler. When invoking clang we would provide ‘-mcpu=chip_v1’ or ‘-mcpu=chip_v2’, and the mnemonic ‘LD32’ is only valid when compiling for ‘chip_v1’, while ‘LD.32’ is only valid when compiling for ‘chip_v2’. But I will study the

"Martin J. O'Riordan" <martin.oriordan at movidius.com> writes: > Thanks Ahmed and also Alex for your replies. > > This is more or less what I was realising, but it is a great > confidence booster to know that it is the correct way also. I can > replace all of my various 'Select*' specialisations with version that > use

I am seeing failures in two tests after migrating to v5.0 final, these are: std/language.support/support.limits/limits/numeric.limits.members/quiet_NaN. pass.cpp and: std/language.support/support.limits/limits/numeric.limits.members/signaling_ NaN.pass.cpp However, these are new tests and it turns out that the underlying problem is that the builtin '__builtin_nanl("")' is

It occurred to me that instead of the various breakout 'Select*' functions returning the 'SDNode*' result, maybe I should be calling: ReplaceNode(N, newValue); return; or: SelectCode(N); return; Perhaps? MartinO From: Martin J. O'Riordan [mailto:martin.oriordan at movidius.com] Sent: 28 June 2016 16:49 To: 'LLVM Developers'

Yep, done that already, but it is not at all a good fit when the device is inside a drone flying around ;-) What we do have, is a fake file-system that keeps everything in memory, and after the profiling is completed we offload it for analysis. I guess I was hoping that there would be a more robust system agnostic implementation. Use of ‘mmap’ is similarly constraining. MartinO

Martin hi. It seems like you have in fact understood the offered solution, and its disadvantages. The thing is, that as far as I understand Tblgen (and I think I do :-) ), The idea behind it is that records only have state (i.e., fields), and not a behavior (i.e., methods) - so dynamic evaluation can only be achieved by built-in functions. (e.g., !if(), !foreach() etc...). Maybe you can try

I've no idea, but without it, the 'std::to_string' definitions are not enabled! -----Original Message----- From: Renato Golin [mailto:renato.golin at linaro.org] Sent: 06 July 2016 19:35 To: Martin.ORiordan at movidius.com Cc: LLVM Developers <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] GCC prerequisites for building LLVM head? On 6 July 2016 at 19:02, Martin J.

I was adding a new option for our backend, and because of the nature of the option I wanted to use an 'enum', something like: enum Direction { left, right, up, down }; cl:opt<Direction> myOpt("option-switch", cl::init(up), cl::desc("what it does"), cl::Hidden); This bit is fine, but then I wanted to change it on the command-line to

Thanks again Elior, Yes, I tried using '!if', etc. but I just get type mismatches for the initializer (int) - probably something daft I'm doing :-( MartinO -----Original Message----- From: Malul, Elior [mailto:elior.malul at intel.com] Sent: 29 September 2013 09:19 To: Martin.ORiordan at movidius.com; llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] Tblgen and computed expressions

I just checked with '-E' and I am picking up '<string>' from: /usr/lib/gcc/i686-pc/cygwin/4.9.3/include/c++/string all other C++ headers are coming from the same place. The 'std::to_string' functions are not present in '<string>', but they are located in '<bits/basic_string.h>' - which is included. Perhaps it is a broken Cygwin

On Tue, Jun 28, 2016 at 8:53 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It occurred to me that instead of the various breakout ‘Select*’ functions > returning the ‘SDNode*’ result, maybe I should be calling: > > > > ReplaceNode(N, newValue); > > return; > > or: > > SelectCode(N); > > return; > > >

Hi Mehdi and my apologies for the delay in responding - the day job got in the way :-) Our target is still out-of-tree so my reasons for extending the IR would be eliminated if we were a proper part of LLVM, which I would like to do when the time is right for us. My extensions are quite simple really, and I expect that they will be wanted in the TRUNK sometime anyway. At the moment I only have