similar to: Removing LLVM_ALWAYS_INLINE from ADT classes

On Sat, Jan 5, 2019 at 12:38 AM Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This makes sense to me. > > One concern is that this in itself will slow down the build, since > tablegen will get even slower. Ideally, there would be some (perhaps > default?) configuration where we build the tablegen binaries with > optimizations on and then use

IIRC the issues with defaulting to –DLLVM_OPTIMIZE_TABLEGEN=ON came up in two places: First, if it's not a Debug build, this actually slows down the build. The defaulting has to be for Debug config only. This is arguably bad UI, because it makes the default modal, but there's a clear benefit in build time so I think we can live with that. Second, if it's a multi-config builder (e.g.

On Wed, Jan 9, 2019 at 9:38 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > On Fri, Jan 4, 2019 at 3:15 PM Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> I would like to propose, based on a previous discussion on llvm-dev, >> the following change. >> https://reviews.llvm.org/D56337 >> >> The

On Thu, Jan 10, 2019 at 1:20 PM Davide Italiano <davide at freebsd.org> wrote: > > On Wed, Jan 9, 2019 at 2:18 PM Davide Italiano <davide at freebsd.org> wrote: > > > > On Wed, Jan 9, 2019 at 9:38 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > > > > > > > > > On Fri, Jan 4, 2019 at 3:15 PM Davide Italiano via llvm-dev

On Thu, Jan 17, 2019 at 2:17 PM David Greene <dag at cray.com> wrote: > Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > As mentioned elsewhere in the thread, building TableGen with > > Debug+Asserts isn't only useful for people who want to debug TableGen > > itself. It's useful for anybody modifying .td as many checks on .td >

On Sun, 6 Jan 2019 at 00:42, Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Jan 4, 2019 at 3:52 PM Paweł Bylica via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Sat, Jan 5, 2019 at 12:38 AM Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> This makes sense to me.

On Mon, Jan 7, 2019 at 8:39 AM <paul.robinson at sony.com> wrote: > > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Alex > > Bradbury via llvm-dev > > Sent: Monday, January 07, 2019 11:33 AM > > To: Mehdi AMINI > > Cc: LLVM Dev > > Subject: Re: [llvm-dev] Removing

On Fri, Jan 11, 2019 at 11:18 AM Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > After yet another round of discussions, the plan is that of trying not > to slap another attribute on the members, instead going for making > OPTIMIZED_TLBGEN the default and removing always_inline. > I'll do some testing locally (for the Ninja and the Xcode build >

On Tue, Jan 15, 2019 at 3:44 PM Davide Italiano <davide at freebsd.org> wrote: > On Mon, Jan 14, 2019 at 1:52 PM Reid Kleckner <rnk at google.com> wrote: > > > > On Fri, Jan 11, 2019 at 11:18 AM Davide Italiano via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > >> After yet another round of discussions, the plan is that of trying not

On Mon, 14 Jan 2019 at 23:11, Nico Weber via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I agree that shelling out to `cmake --build` as a build step is pretty ugly. > > It seems kind of simpler to me to just always build Support and TableGen with O3 always, even in debug builds. Most people don't debug code in Support and TableGen, and there could be a disable switch

Historically there was a request to make LLVM_OPTIMIZED_TABLEGEN On by default for debug builds, which I discouraged. At the time it was suggested that workflow was fairly new and untested in a lot of build configurations. Today I believe that situation is slightly better. I believe there are still issues with it not working correctly in the Xcode generator, but I know people have used it

On Mon, Mar 16, 2015 at 11:00 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, Mar 16, 2015 at 10:52 PM, Davide Italiano <davide at freebsd.org> > wrote: >> >> On Mon, Mar 16, 2015 at 1:54 AM, Davide Italiano <davide at freebsd.org> >> wrote: >> > >> > Shankar's parallel for per-se didn't introduce any

On Sat, Dec 15, 2018 at 9:37 PM Chandler Carruth <chandlerc at gmail.com> wrote: > > On Sat, Dec 15, 2018 at 6:13 PM Davide Italiano <davide at freebsd.org> wrote: >> >> On Sat, Dec 15, 2018 at 12:02 PM Vedant Kumar via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > >> > Hi, >> > >> > > On Dec 15, 2018, at 10:32

On Mon, Mar 16, 2015 at 1:54 AM, Davide Italiano <davide at freebsd.org> wrote: > > Shankar's parallel for per-se didn't introduce any performance benefit > (or regression). > If the change I propose is safe, I would like to see Shankar's change > in (and this on top of it). > I have other related changes coming next, but I would like to tackle > them one at

With the correct list this time. On Wed, Sep 9, 2015 at 6:59 PM, Davide Italiano <davide at freebsd.org> wrote: > Hi, > in the last month I spent some time implementing the missing MachO > specific features in llvm-readobj, and converting all the remaining > tests that used macho-dump to the new format. > llvm-readobj should have all the functionality that macho-dump had. If

I'm not entirely sure whether this is worth an RFC, but, just in case. On bugzilla Eli pointed out we currently match a specific sequence of instructions to cls ( https://reviews.llvm.org/rL206079), and given how fragile this is, it could be better to just introduce an intrinsic for it (and presumably, teach peephole optimizations to lower a sequence to that intrinsic). I wonder what folks are

On Sat, Dec 15, 2018 at 12:02 PM Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > > On Dec 15, 2018, at 10:32 AM, Brian Gesiak via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Hello all! > > > > I find that using lldb to debug LLVM libraries can be super > > frustrating, because a lot of LLVM classes, like

While playing with sanitizer in a downstream project, I found out this. /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:207:32: error: reference to type 'std::unique_ptr<MCCodeEmitter>' could not bind to an lvalue of type 'llvm::MCCodeEmitter *' UseDwarfDirectory, IP, CE, MAB, ShowInst));

Thank you. I went ahead with a speculative fix in r331568. I'm not familiar _at all_ with the tool, so, although the fix was straightforward, another pair of eyes from somebody familiar with the tool would be appreciated. On Fri, May 4, 2018 at 5:10 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > It worked in August. > Last time I’ve asked (again, in August) someone did

Hi everybody. NewGVN was recently committed and a few minute ago I added a flag to enable the new experimental pass. For the brave soul, passing `-mllvm -enable-newgvn` should do the trick. We'll be happy to receive bug reports to analyze/fix, bonus point if they contain a synthetic/reduced testcase. Open a bug linked to https://llvm.org/bugs/show_bug.cgi?id=30995 would be probably best so