similar to: MachineIRBuilder API

I’m less interested in literally passing the output of one as an argument to the next such that argument evaluation order matters. Intermediate register variables are fine. It would still be less code to have tmp = buildFoo(), buildFoo(tmp) than the current code required to manage the register -Matt From: <daniel_l_sanders at apple.com> on behalf of Daniel Sanders <daniel_l_sanders at

Greetings, I am having trouble getting the Kaleidoscope example to build from tutorial #3 on Mac OS X 10.6.2. I didn't have too much trouble getting llvm-2.6 and llvm-gcc-frontend to build. Thanks for the help. Here are the steps I followed: Environment variables for build export LLVMOBJDIR=/opt/llvm export TARGETOPTIONS='--with-arch=nocona --with-tune=generic' export

Hi, Mips32 has 64 bit floating point instructions, while i64 instructions have to be emulated with i32 instructions. This means that G_LOAD should be custom legalized for s64 integer value, and be legal for s64 floating point value. There are also other generic instructions with the same problem: G_STORE, G_SELECT, G_EXTRACT, and G_INSERT. There are also other configurations where integer

...Continued from the other email Removing the defs section We can potentially infer quite a lot of the defs section but it requires both a complicated ruleset and that tblgen spends processing time doing the inferencing. That processing time is potentially significant for large combiners and for that reason we need to be careful not to let inferencing become a burden on tblgen. My main worry

> On Nov 29, 2018, at 02:02, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > On 27.11.18 19:01, Daniel Sanders wrote: >> ...Continued from the other email >> _Removing the defs section_ >> We can potentially infer quite a lot of the defs section but it requires both a complicated ruleset and that tblgen spends processing time doing the inferencing. That

Hi Daniel, On 13.09.2018. 19:32, Daniel Sanders wrote: > Could you clarify what you mean here? The new legalizer info can > define this with: >     getActionDefinitionsBuilder(G_SELECT).clampScalar(1, s32, s32) > so I'm guessing you mean that code to mutate the G_SELECT is currently > missing Yes, LegalizerHelper::widenScalar widens only TypeIdx==0, it doesn't do that

On Sep 22, 2009, at 4:49 PM, Talin wrote: > > // Calculate the size of the specified LLVM type. > Constant * DebugInfoBuilder::getSize(const Type * type) { > Constant * one = ConstantInt::get(Type::Int32Ty, 1); > return ConstantExpr::getPtrToInt( > ConstantExpr::getGetElementPtr( > ConstantPointerNull::get(PointerType::getUnqual(type)), >

> On Nov 10, 2018, at 03:28, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Thank you for the detailed reply! There's a lot to digest :) Let me try to address most of it. > > > [snip] >>> I also think you should have 'ins' and 'outs' separately; after all, a predicate may have to do a combined check on two matched registers / operands,

On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> wrote: > On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia at gmail.com> wrote: >> So, one feature of the late, lamented DebugInfoBuilder that I am missing >> quite badly, and which is not available in the current DIFactory, is the >> ability to specify structure offsets abstractly. The

Hi All, I've more or less finished updating the examples to the DAG style we were talking about. Hopefully I haven't forgotten anything, there was a lot to keep track of :-). Overall, I think there's a couple places where things get a a little awkward (mainly debug info) but things generally look good to me. A Simple Example def : GICombineRule<(defs reg:$D, reg:$S),

Here's a sketch of what I am proposing for ConstantBuilder. I'd like feedback on naming conventions, doc comments, etc. //===-- llvm/Support/ConstantBuilder.h - Builder for Constants --*- C++ -*-===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. //

Thanks Nicolai! > On Nov 9, 2018, at 02:55, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Hi Daniel, > > Lots of good stuff in there! I especially like the design for specifying out-of-line predicates. I have a couple of small comments and one major one below. > > > On 09.11.18 02:42, Daniel Sanders via llvm-dev wrote: >> _Passing arbitrary data from

On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com>wrote: > On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> > wrote: > > On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia at gmail.com> wrote: > >> So, one feature of the late, lamented DebugInfoBuilder that I am missing > >> quite badly, and which is not

Hi All, I've been working on the GlobalISel combiner recently and I'd like to share the plan for how Combine Rules will be defined in GlobalISel and solicit feedback on it. This email ended up rather long so: TL;DR: We're planning to define GlobalISel Combine Rules using MIR syntax with a few bits glued on to interface with the algorithm and escape into C++ when we need to.

On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: > > On Sep 22, 2009, at 4:49 PM, Talin wrote: > >> >> // Calculate the size of the specified LLVM type. >> Constant * DebugInfoBuilder::getSize(const Type * type) { >> Constant * one = ConstantInt::get(Type::Int32Ty, 1); >> return ConstantExpr::getPtrToInt( >>

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

> On Nov 29, 2018, at 01:57, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Hi Daniel, > > > On 27.11.18 18:59, Daniel Sanders wrote: >> I've more or less finished updating the examples to the DAG style we were talking about. Hopefully I haven't forgotten anything, there was a lot to keep track of :-). Overall, I think there's a couple places where

On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: >> >> On Sep 22, 2009, at 4:49 PM, Talin wrote: >>> >>> // Calculate the size of the specified LLVM type. >>> Constant * DebugInfoBuilder::getSize(const Type * type) { >>>    Constant * one =

On Tue, Sep 22, 2009 at 4:49 PM, Talin <viridia at gmail.com> wrote: > > > On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> > wrote: >> >> On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> >> wrote: >> > On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia at gmail.com> wrote: >>

---- On Wed, 06 Sep 2017 14:34:27 -0700 toddandmargo via samba wrote ---- > > >---- On Wed, 06 Sep 2017 14:11:54 -0700 Rowland Penny via samba<samba at lists.samba.org> wrote ---- > > On Wed, 06 Sep 2017 13:32:39 -0700 > > toddandmargo via samba <samba at lists.samba.org> wrote: > > > > > > > > [global] > > > workgroup = xxxxx