similar to: Understanding failed assert in reg pressure reduction list scheduler

Could you post the .ll file with the testcase? -Krzysztof On 7/29/2016 2:38 PM, Elliot Colp via llvm-dev wrote: > Hi all, > > I'm currently investigating a bug which is causing an assert to fail in > lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp. See > https://llvm.org/bugs/show_bug.cgi?id=28753 for repro information. > > To my knowledge, this problem only occurs with

Sure, I've attached it to the bug report. Direct link is here: https://llvm.org/bugs/attachment.cgi?id=16840 - Elliot "llvm-dev" <llvm-dev-bounces at lists.llvm.org> wrote on 2016/07/29 03:46:41 PM: > From: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Date: 2016/07/29 03:46 PM > Subject: Re: [llvm-dev]

Hi everybody, I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment - i.e. data that needs to be touched by the dynamic linker even though it's ultimately read-only, and data that cannot be shared between multiple processes using LLVM. It turns out that a solid ~1.3MB of that data is in the tablegen'd MCInstrDesc tables - there a pointers for ImplicitUses,

On 09.05.2016 05:19, Benjamin Kramer wrote: > On Mon, May 9, 2016 at 5:35 AM, Nicolai Hähnle <llvm-dev at lists.llvm.org> wrote: >> Hi everybody, >> >> I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment >> - i.e. data that needs to be touched by the dynamic linker even though it's >> ultimately read-only, and data that cannot be

Hi, I have an assert firing due to PickNodeToScheduleBottomUp(): 1. having a CallResource in use pushing an interference of current SUnit. 2. having no more SUnits in the AvailableQueue 3. The only interference being the SUnit that just failed due to a Call Resource. 4. An attempt to duplicate this node which has the 'Call Resource' as a physical register. Thus the call

Hi, I have reasoned through and believe the problem is with the PrescheduleNodesWithMultipleUses. Take the following DAG (arrow to predecessor): Destroy Destroy ^ ^ | | | | SetUp----->PredSU <-----SU ^ ^ ^ | | | | | | ----------- |

Here is a bit more data. After PrescheduleNodesWithMultipleUses has been run, the following Predecessor/Successor links are 'dumpAll'ed. (I attach the full dumpAll before & after "Prescheduling SU #7 next to PredSU #4 to guide scheduling in the presence of multiple uses") SU(3) Predecessors: val SU(5): Latency=1 ch SU(7): Latency=1 val SU(7): Latency=1 SU(7):

Hi Pengxuan, I just saw that the newly added AOSP buildbot allready builds LLVM very nicely. However, it is still red due to the following assertion: FAILED: out/target/product/angler/obj_arm/STATIC_LIBRARIES/libskia_static_intermediates/src/core/SkOpts.o /bin/bash -c "PWD=/proc/self/cwd ulimit -t 180; llvm.inst/bin/clang++ -I external/libjpeg-turbo -I external/libpng -I

> On Aug 30, 2017, at 1:43 PM, Matthias Braun <matze at braunis.de> wrote: > > That means you cannot use the code from RegisterPressure.{cpp|h} to compute this. The other liveness analysis we have in llvm codegen is LiveIntervals (LiveItnervalAnalysis) which gives you a list of liveness segments of a given vreg (the same representation is used in most linear scan allocators even

Hi, At the moment the same test is being ran twice - same output so pointless! I believe this may not be what was intended. The change below runs the virtual register test the second time on the Predecessor SUnit. Robert diff --git a/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp b/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp index f5fe168..6e888da ---

On Sep 23, 2011, at 1:38 PM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> It appears that tablegen is inferring the 'type' of an individual >> register by enumerating all the register classes it appears in. Some >> things, like using implicit defs in SDNodes, only works for registers >> with a unique type. My

Hello LLVM, I'd like to check TSFlags in my AsmBackend code. However AsmBackend objects don't have a reference to MCInstrInfo, which is the only way I've seen to reach TSFlags. A quickie grep shows that none of the existing targets check TSFlags in their AsmBackends. Is there any reason I shouldn't check TSFlags in AsmBackend? If not, what's the best way to go about it?

We are having a strange issue with LLVM 2.6 running on MSVC in debug mode. When compiling in debug mode, iterator debugging is turned on. In the case of std::priority_queue, iterator debugging checks to make sure that the queue is in proper order and will abort if it isn't. Recently, we have started to see this error in the DAG. Call Stack: SelectionDAGISel::runOnMachineFunction:339

On Thu, Aug 22, 2013 at 4:15 AM, Robert Lytton <robert at xmos.com> wrote: > > > Outstanding issues > ============ > > 1. Is it too aggressive in searching predecessors and successors? > Should the algorithm give up and assume the worst if the depth of > search reaches a predefined limit? > > 2. Should the initial search for 'SetUp1' and

Am Mittwoch, 26. September 2012, 11:18:20 schrieb Jakob Stoklund Olesen: > Hi Christoph, > > As you noticed, MCInstrDesc doesn't distinguish between variadic uses and > defs. Since variadic instructions will always require some kind of special > handling, it doesn't seem worthwhile to make the model more detailed. I don't see what makes them so different from other

Hello, I'm currently working on a rich disassembler for some ARM/Thumb environment. I wanted to keep most classes independent of the architecture, so I use MCInstrInfo and MCInstrAnalysis to find branch instructions (and other instructions writing to the program counter) and to differentiate between register definitions and uses to track all instructions the branch depends on. This works

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > It appears that tablegen is inferring the 'type' of an individual > register by enumerating all the register classes it appears in. Some > things, like using implicit defs in SDNodes, only works for registers > with a unique type. My WIDE32 class caused GR32 registers to no > longer have a unique type, breaking

Hi, I'm not sure this is a bug, so I thought I'd bounce it off the help group first. I had a dataset which I was subsetting, and occasionally I get an empty subset. If I don't check for emptiness and go straight to a which.min call on the subset, the program gets a big negative number back. One-line Example: > which.max(NULL) [1] -2147483647 This caused an indexing

Hi, I wonder if it is okay to add an operand that is not part of MCInstrDesc to an MI after isel? There are things going on like instruction combining, rematerialization etc, which may call MI with TI->get(opcode). If an MI would get replaced with a new instance of itself in this way, any previously added operands would get lost, as they are not part of the MCInstrDesc. RegAlloc, does

Hi all, I need to figure out why InstrEmitter::EmitMachineNode assumes that when the number of outputs of a MachineSDNode is greater than the number of defs in the corresponding MCInstrDesc, the outputs in the difference will be placed into physical registers as opposed to virtual registers. The specific line in question is: bool HasPhysRegOuts = NumResults > NumDefs &&