similar to: Question about LLVM Building Error with "-DLLVM_ENABLE_DUMP" and "RelWithDebInfo"

> On Apr 7, 2017, at 4:45 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I think the idea is to keep NDEBUG out of headers when possible. So I think this should better be something like: > > -#ifndef NDEBUG > void dumpUses(unsigned RegNo) const; > -#endif > > to be inline with various other dumpers (like MachineInstr::dump(),

Presently several of our headers have definitions like: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) void dump() const; #endif Would it make sense to modify the build system to define LLVM_ENABLE_DUMP in config.h on debug builds? Then we could wrap dump methods just based on LLVM_ENABLE_DUMP instead of two variables. -Chris > On Apr 10, 2017, at 1:34 PM, Robinson, Paul via llvm-dev

> On Apr 10, 2017, at 12:37 PM, Matthias Braun <mbraun at apple.com> wrote: > > The situation is not consistent. Yes there are several places where we have the #if in the headers however there are far more cases where it is not. Some points here: > > - This whole LLVM_DUMP_FUNCTION/LLVM_ENABLE_DUMP is about enabling the linker to strip (or not strip) the dumping function in

Hi Matthias, >Jingu: Why do you even want a configuration that has LLVM_ENABLE_DUMP but does not have asserts enabled at the same time? My colleague and I am doing custom project using clang/llvm. We have always wanted to use the IR Value's dump() to check our implementation correctly with Debug, Release and another builds. We thought the LLVM_ENABLE_DUMP is for it. If Chris fixes

On 09/25/2017 06:19 PM, Matthias Braun wrote: > >> On Sep 25, 2017, at 6:03 PM, David Keaton via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 09/25/2017 02:53 PM, Matthias Braun via llvm-dev wrote: >>> The dump methods can be included in the release builds anyway by enabling LLVM_ENABLE_DUMP. >> >> Is there a way to pass

> On Sep 26, 2017, at 7:04 AM, David Keaton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 09/25/2017 06:47 PM, David Keaton via llvm-dev wrote: >> On 09/25/2017 06:19 PM, Matthias Braun wrote: >>> >>>> On Sep 25, 2017, at 6:03 PM, David Keaton via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>>> >>>> On

On 09/25/2017 06:47 PM, David Keaton via llvm-dev wrote: > On 09/25/2017 06:19 PM, Matthias Braun wrote: >> >>> On Sep 25, 2017, at 6:03 PM, David Keaton via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> >>> On 09/25/2017 02:53 PM, Matthias Braun via llvm-dev wrote: >> In the meantime `cmake

2017-09-26 11:54 GMT-07:00 Matthias Braun via llvm-dev < llvm-dev at lists.llvm.org>: > > > On Sep 26, 2017, at 7:04 AM, David Keaton via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On 09/25/2017 06:47 PM, David Keaton via llvm-dev wrote: > >> On 09/25/2017 06:19 PM, Matthias Braun wrote: > >>> > >>>> On Sep 25,

On 09/25/2017 02:53 PM, Matthias Braun via llvm-dev wrote: > The dump methods can be included in the release builds anyway by > enabling LLVM_ENABLE_DUMP. Is there a way to pass LLVM_ENABLE_DUMP into cmake from outside without changing any of the configuration files? With Chapel's use of LLVM, we try to avoid modifying any of the source files that come from the LLVM

> On Sep 25, 2017, at 6:03 PM, David Keaton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 09/25/2017 02:53 PM, Matthias Braun via llvm-dev wrote: >> The dump methods can be included in the release builds anyway by enabling LLVM_ENABLE_DUMP. > > Is there a way to pass LLVM_ENABLE_DUMP into cmake from outside without changing any of the configuration files?

Hi to everyone, while working with the machine scheduler for a personal project, I came up with the necessity of inserting a backup boundary in the MachineSchedulerStrategy -- specifically, the PostGenericScheduler -- to hold a copy the scheduler's state, in order to implement a really trivial (and really inefficient) backtracking mechanism. This approach leads to a subtle "segmentation

Hi JinGu, We currently have the ResourceCycles list to indicate the number of cpu cycles during which a resource is reserved. We could simply add a ResourceDelay with similar grammar. The MachineScheduler could be taught to keep track of the first and last time that a resource is reserved. Note that the MachineScheduler will work with the instruction itineraries if you choose to implement them.

On Mar 4, 2014, at 10:05 AM, Pete Cooper <peter_cooper at apple.com> wrote: > > On Mar 3, 2014, at 2:21 PM, Andrew Trick <atrick at apple.com> wrote: > >> >> On Mar 3, 2014, at 8:53 AM, Pierre-Andre Saulais <pierre-andre at codeplay.com> wrote: >> >>> Hi Andrew, >>> >>> We are currently using a custom model where

On Feb 19, 2014, at 1:54 PM, jingu <jingu at codeplay.com> wrote: > Hi Andy, > > I am trying to schedule and packetize instructions for VLIW at post-RA > stage or final codegen stage, where code transformations are not allowed > any more, because hardware can not resolve resource conflict. There is a > simple example as following: > > ADD dest_reg1, src_reg1,

>Resources and latency are not tied. An instruction is mapped to a scheduling class. A scheduling class is mapped to a set of resources and a per-operand list of latencies. Thanks for your kind explanation. Our heuristic algorithm have needed the latency and the resource per operand to check resource conflicts per cycle. In order to support this with LLVM, I expected a per-operand list of

On Mar 3, 2014, at 8:53 AM, Pierre-Andre Saulais <pierre-andre at codeplay.com> wrote: > Hi Andrew, > > We are currently using a custom model where scheduling information is attached to each MCInstrDesc through tablegen, and we're trying to move to one of LLVM's models. > > To expand on what JinGu mentioned, our target has explicit ports that are used to read and

Hi, I'm working on defining a SchedMachineModel for the Southern Islands family of GPUs, and I have two questions related to the MachineScheduler. 1. I have a resource that can process 15 instructions at the same time. In the TableGen definitions, should I do: def HWVMEM : ProcResource<15>; or let BufferSize = 15 in { def HWVMEM : ProcResource<1>; } 2. Southern Islands has

On Jul 22, 2013, at 11:50 AM, Tom Stellard <tom at stellard.net> wrote: > Hi, > > I'm working on defining a SchedMachineModel for the Southern Islands > family of GPUs, and I have two questions related to the > MachineScheduler. > > 1. I have a resource that can process 15 instructions at the same time. > In the TableGen definitions, should I do: > > def

On Sun, Oct 15, 2017 at 12:40 PM, Don Hinton <hintonda at gmail.com> wrote: > On Sun, Oct 15, 2017 at 8:34 AM, Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> FWIW, most of the ones I was fixing up were guarded by NDEBUG instead >> of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link >> errors for me -- the only one I struggled with

Hi all, These two cmake configuration are using different optimization levels (O2 vs O3). What is the rational for that? I know that O1 is "supposingly" more friendly for debugging, but I don't think we make such claim for O2 vs O3, are we? I'd expect RelWithDebInfo to be what the name says, i.e. Release + debug-information. -- Mehdi