search for: duskborn

> On May 19, 2015, at 7:32 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Tue, May 19, 2015 at 4:05 PM, Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote: > >> On May 19, 2015, at 9:48 AM, Neil Henning <llvm at duskborn.com <mailto:llvm at duskborn.com>> wrote: >> >> The 'backend' in this context is purely so that we can then enable Clang to target SPIR-V in the same consistent manner to all the other targets it supports. > > This seems like a terrible reason to choose the arch...

...unctions from there, linking against -lmpfr and -lgmp. I admit that this option would indeed add another dimension to the testing matrix. Do you have an alternative solution or a preferred solution of those I enumerated earlier? Cheers, James On Mon, 4 Apr 2016 at 15:24 Neil Henning <llvm at duskborn.com> wrote: > Hey James, > > I really fundamentally dislike libMPFR. > > License of the codebase aside, would a dependency be on the built .so, or > would it be that we'd want to pull in the code and build that? > > My worry if we do bring it in even as a soft depend...

> On May 20, 2015, at 7:13 AM, Neil Henning <llvm at duskborn.com> wrote: > > On 20/05/15 08:37, Owen Anderson wrote: >> >>> On May 19, 2015, at 7:32 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: >>> >>> >>> >>> On Tue, May 19, 2015 at 4:05 PM, Ow...

> On May 19, 2015, at 9:48 AM, Neil Henning <llvm at duskborn.com> wrote: > > The 'backend' in this context is purely so that we can then enable Clang to target SPIR-V in the same consistent manner to all the other targets it supports. This seems like a terrible reason to choose the architecture of how it’s implemented in LLVM. The clang d...

...should probably do something similar to the > autoconf build if possible and just have subdirectories equal to the targets > to build. I'm not sure if this is possible etc... could try some setting > etc. > > -eric > > On Mon, Mar 9, 2015 at 9:11 AM Neil Henning <llvm at duskborn.com> wrote: >> >> Hey all, >> >> Quick query on out of tree target support - at present I can drop a folder >> Foo into <llvm>/lib/Target/Foo and use the CMake option >> LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to pick up my target. The issue is that I >&gt...

On 09/27/2017 05:21 AM, Tomeu Vizoso wrote: > On 07/31/2017 02:30 PM, Nicholas Wilson via llvm-dev wrote: >> >>> On 31 Jul 2017, at 3:23 pm, Neil Henning <ll... at duskborn.com> wrote: >> >> Moving forward, other than securing the triples spirv32, spirv64, and spirvlogical from LLVM, how can we go about coordinating efforts? I feel that having one backend is a better use of everybody’s time than having three. If we don't get around to anything I’m s...

> On 31 Jul 2017, at 3:23 pm, Neil Henning <llvm at duskborn.com> wrote: > > Yup to a third backend sorry ;) > > We want a backend in tip LLVM - but I think approaching this from OpenCL SPIR-V's perspective (whereby almost everything in LLVM is 1:1 implementable in OpenCL SPIR-V) will cause a headache when adding Vulkan SPIR-V's more...

> On May 19, 2015, at 1:25 AM, Neil Henning <llvm at duskborn.com> wrote: > > The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V’. The *entire point* of my email was that that is only one of two use cases of SPIR-V. As I said above, it’s a serialization...

On 07/31/2017 02:30 PM, Nicholas Wilson via llvm-dev wrote: > >> On 31 Jul 2017, at 3:23 pm, Neil Henning <ll... at duskborn.com> wrote: > > Moving forward, other than securing the triples spirv32, spirv64, and spirvlogical from LLVM, how can we go about coordinating efforts? I feel that having one backend is a better use of everybody’s time than having three. If we don't get around to anything I’m sure we...

> On May 19, 2015, at 1:25 AM, Neil Henning <llvm at duskborn.com> wrote: > > The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V'. There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics...

Hey all, Quick query on out of tree target support - at present I can drop a folder Foo into <llvm>/lib/Target/Foo and use the CMake option LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to pick up my target. The issue is that I still need to patch the one LLVMBuild.txt file in <llvm>/lib/Target with; |iff --git a/lib/Target/LLVMBuild.txt b/lib/Target/LLVMBuild.txt index 4112046..6e42cbe

> On May 18, 2015, at 2:09 PM, Sean Silva <chisophugis at gmail.com> wrote: > > From an end-user's perspective it sounds like the use case for SPIR-V though is a lot more similar to a target though. E.g. the user is notionally telling clang "target SPIR-V" (including doing any IR optimizations, any special "codegenprepare" special passes, etc.), rather than

Dear LLVM devs, I just submitted a patch: http://reviews.llvm.org/D10149. However, Phabricator is warning me that "this revision needs review, but there are no reviewers specified". How should I determine who the reviewers should be? Thanks, Alex Dowad -------------- next part -------------- An HTML attachment was scrubbed... URL:

...nd pass it on to anyone else you think may be interested. Please send any tips or feedback to <asb at asbradbury.org>, or @llvmweekly or @asbradbury on Twitter. ## News and articles from around the web Neil Henning has written a short post on [how to read and write LLVM bitcode](http://www.duskborn.com/how-to-read-write-llvm-bitcode/). ## On the mailing lists * Yaxun (Sam) Liu [proposes](http://lists.llvm.org/pipermail/cfe-dev/2018-March/057426.html) adding a HIP language mode to Clang. HIP is a language with similarities to CUDA. * Michael Spencer [proposes using Markdown for LLVM docume...

Hi Neil, > Please not (1). Could you please elaborate on your concern a bit more? Cheers, James On Mon, 4 Apr 2016 at 15:18 Neil Henning via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Please not (1). > > Cheers, > -Neil. > > > On 04/04/16 14:59, James Molloy via llvm-dev wrote: > > Hi, > > Clang is currently unable to constant fold calls to

Hey Tom, Really it was at the behest of the replies - we got a lot of feedback from the mailing list that indicated we'd be putting extra workload of people changing features of the IR if we didn't follow the same mechanisms of the other backends (mostly led by Chandler's very astute comments on the subject). Cheers, -Neil. On 07/07/15 14:43, Tom Stellard wrote: > On Tue, Jul

...as an optional program serialization format would be fantastic. I think it would make it even easier for LLVM-based tools to be integrated into GPU authoring and execution pipelines. I’m really excited to see this moving forward! -Chris > On May 14, 2015, at 1:56 AM, Neil Henning <llvm at duskborn.com> wrote: > > Hey Reid, > > (Donning my Khronos hat here) - it would make sense to keep the code together within a SPIRV backend, in that there are many helper constructs shared by both the reader/writer - we realised though that this would be a non-standard thing to do in terms...

On Wed, May 13, 2015 at 6:11 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 13 May 2015, at 13:56, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > > > Khronos Group SPIR WG is working on a bi-way converter between LLVM > bitcode and SPIR-V ( > https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf ) binary and > is willing to upstream

Yet another implementation of the backend, heh. I’d just started in earnest writing a tablegen based one, with the main goal of fixing the intrinsics to actually be intrinsics. I think it would be a good idea to join forces with the folk at KhronosGroup and consolidate the work done for inclusion into LLVM. Nic > On 17 Jul 2017, at 9:55 pm, Neil Henning via llvm-dev <llvm-dev at

Hey all, For LinkModules, /*dest*/ is a fully materialized module, /*src*/ is a lazily loaded module. From what I understood, getLinkedToGlobal() is finding the function in /*src*/ that matches some function declaration in /*dest*/, and given that /*src*/ is lazily loaded it could be un-materialized. The functions I need brought in from /*src*//**/ into /*dest*/ are always declarations in