similar to: [LLVMdev] [RFC] Hexagon insn table refactoring

Sure I will split it and put it in two patches. Give me few hours. I need to test those patches. Sirish On 4/19/2012 8:40 AM, Tom Stellard wrote: > On Wed, Apr 18, 2012 at 11:18:05PM -0500, Sirish Pande wrote: >> Hi, >> >> Here's a patch for Hexagon Packetizer for review. This patch does >> not yield any warnings. >> > Would it be possible to split this

The Hexagon part is fixed in r364790. -- Krzysztof Parzyszek kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> LLVM compiler development From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Joan Lluch via llvm-dev Sent: Sunday, June 30, 2019 2:04 PM To: llvm-dev <llvm-dev at lists.llvm.org> Subject: [EXT] [llvm-dev] [hexagon][PowerPC] code regression

Hi, I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some related commits later on, and the assertion I get on the latest trunk (r164162) differs from

Ok, after a long detour I am back to where I have started. I think there is a problem at dep DAG construction. Let me try to convince you. Here is the C code we are dealing with: push () { struct xx_stack *stack, *top; for (stack = xx_stack; stack; stack = stack->next) top = stack; yy_instr = top->first; } If the loop never iterates, "top" will have

Sergei, Absolutely right, the copy/ldriw should not be reordered. I was attempting to explain that I consider it a phi-elimination bug, not a DAG builder bug. Liveness will also have problems with this code in the long run. To avoid confusion, I filed PR13112: Phi elimination generates uninitialized vreg uses, and disabled the SSA check until its fixes in r158461. However, your C code is also

Andy, You are probably right here - look at this - before phi elimination this code looks much more sane: # *** IR Dump After Live Variable Analysis ***: # Machine code for function push: SSA Function Live Outs: %R0 BB#0: derived from LLVM BB %entry %vreg5<def> = IMPLICIT_DEF; IntRegs:%vreg5 %vreg4<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg4

On Mon, Jun 4, 2012 at 11:22 AM, Sebastian Pop <spop at codeaurora.org> wrote: >> Why don't you call it with "Promote" instead of >> "Custom" and let the Legalizer do the job? Does it not work? > > I tried this, and the legalizer will happily say that i8 is a legal type > and just return the exact same node: this is because we declared > that

On Jun 13, 2012, at 1:15 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, > > You are probably right here – look at this – before phi elimination this code looks much more sane: > > # *** IR Dump After Live Variable Analysis ***: > # Machine code for function push: SSA > Function Live Outs: %R0 > > BB#0: derived from LLVM BB %entry >

On Mon, 4 Jun 2012 11:41:43 -0500 Sebastian Pop <spop at codeaurora.org> wrote: > On Mon, Jun 4, 2012 at 11:22 AM, Sebastian Pop <spop at codeaurora.org> > wrote: > >> Why don't you call it with "Promote" instead of > >> "Custom" and let the Legalizer do the job? Does it not work? > > > > I tried this, and the legalizer will

Hi All, The following code : void hexagon2( int *a, int *res ) { int i = 100; while ( i-- ) { *res++ = *a++; } } gets compiled as a sub-optimal Software loop on LLVM 9.0 instead of a Hardware loop, whereas it was compiled as a Hardware Loop in LLVM 7.0. This is the final assembly code generated by LLVM 9.0 : .text .file "main.c" .globl hexagon2 // --

On Jun 12, 2012, at 10:22 AM, Sergei Larin <slarin at codeaurora.org> wrote: > > Hello everyone, > > I am working on a release based on the branch 3.1 version of code. > Unfortunately it has enough differences that exact rev does not apply. > I am hitting an assert in liveness update with seemingly trivial code > (attached). > >

Hello everyone, I am working on a release based on the branch 3.1 version of code. Unfortunately it has enough differences that exact rev does not apply. I am hitting an assert in liveness update with seemingly trivial code (attached). /local/mnt/workspace/slarin/tools/llvm-mainline-merged/lib/CodeGen/LiveInter valAnalysis.cpp:1078: void

Since Jakob had expressed some concerns regarding machine-generated files, I asked him by email about his views on this RFC. Here are the emails that we exchanged in attach. Anyone feel free to jump in via the mailing-list. TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum -------------- next

Andy, Jacob, I have ported Hexagon MI scheduler to use the new scheduler infrastructure, but one of my tests triggers an assert in LiveInterval update. On the surface it does not make much sense to me, so I wonder if this is something you readily recognize, before I try to prop it open... The assert is: lib/CodeGen/LiveInterval.cpp:266: llvm::LiveRange*

Andy, I traced my problem to this point: In ScheduleDAGInstrs.cpp we have the following function: /// addVRegDefDeps - Add register output and data dependencies from this SUnit /// to instructions that occur later in the same scheduling region if they read /// from or write to the virtual register defined at OperIdx. /// /// TODO: Hoist loop induction variable increments. This has to be ///

Andy, Thanks for reply. I was able to trace the problem to the MI DAG dep constructor. See this: SU(0): %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 # preds left : 0 # succs left : 0 # rdefs left : 1 Latency : 1 Depth : 0 Height : 0 SU(1): %vreg10<def> = LDriw %vreg9<kill>, 0;

On Wed, Feb 27, 2019 at 04:36:39PM -0800, Daniel Verkamp wrote: > Hello, > > In my testing of crosvm[1] with Linux 4.4.175, I am observing failures > on a 'kevin' Chromebook (RK3399) device - the guest kernel does not > even get to the point of printing its first messages, and the host > seems to be spinning at 100% CPU in KVM_RUN. > > I narrowed this down to the

On Fri, Apr 17, 2020 at 09:50:00PM +0900, Masami Hiramatsu wrote: > On Thu, 16 Apr 2020 17:24:06 +0200 > Joerg Roedel <joro at 8bytes.org> wrote: > Ah, I got it. So you intended to port the instruction decoder to > pre-decompression boot code, correct? Right, it is needed there to decode instructions which cause #VC exceptions when running as an SEV-ES guest. > > The

From: Joerg Roedel <jroedel at suse.de> Add a function to check whether an instruction has a REP prefix. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/include/asm/insn-eval.h | 1 + arch/x86/lib/insn-eval.c | 24 ++++++++++++++++++++++++ 2 files changed, 25 insertions(+) diff --git a/arch/x86/include/asm/insn-eval.h b/arch/x86/include/asm/insn-eval.h index

On 28/02/2019 08:49, Marc Zyngier wrote: > On Thu, 28 Feb 2019 08:16:05 +0000, > Greg KH <gregkh at linuxfoundation.org> wrote: > > Hi both, > >> >> On Wed, Feb 27, 2019 at 04:36:39PM -0800, Daniel Verkamp wrote: >>> Hello, >>> >>> In my testing of crosvm[1] with Linux 4.4.175, I am observing failures >>> on a 'kevin'