similar to: Git repo not updating

Should be fixed now. On Mon, Mar 26, 2018 at 4:40 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > http://llvm.org/git/llvm.git doesn't seem to be picking up new SVN commits. > The most recent one in the git repo that I see is r328483, while in SVN it's > r328492. > Is anyone else seeing this problem? > > -Krzysztof > >

I have made changes in 3 files: LaneBitmask.h, codegenregisters.cpp and miparser.cpp. files are attached here. Now i am getting following errors. which means registerinfo.inc file is not generated successfully. /PIM/lib/Target/X86/MCTargetDesc/X86BaseInfo.h:733:24: error: no member named 'XMM8' in namespace 'llvm::X86' if ((RegNo >= X86::XMM8 && RegNo <=

Hello Krzysztof, The R_CASS definition is as follows: class R_CASS<string n, bits<16> Enc, list<Register> subregs = []> : Register<n> { let Namespace = "X86"; let HWEncoding = Enc; let SubRegs = subregs; } On Thu, Jul 20, 2017 at 4:14 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > I tried reproducing the problem, but the file

I have the same issue, would it be easier and more useful to attach a flag to the instruction to tell the scheduler not to move instructions across this boundary? -Ryan On Tue, Nov 15, 2016 at 5:11 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > You can create a DAG mutation that adds artificial dependencies between A, > B and Z. > > -Krzysztof >

Hi, I have a scenario, roughly like this: if (...) { ... = *x *x = 0 } else { ... = *x *x = 0 } The two sides are functionally different, but both load some value and then set it to 0. After GVN Hoist, I get: *x = 0 if (...) { ... = *x } else { ... = *x } That is, the store was hoisted above the loads. The code is not exactly public, so I

What about the static asserts protecting a Log call and another in the parser? On Wed, Jul 19, 2017 at 2:26 PM Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 7/19/2017 4:18 PM, Craig Topper wrote: > > LaneMask isn't as self contained as it should be. 64 bits is enough > > here. The problem is accidental leaking of the current size. > > > > For

On 7/27/2016 12:17 PM, Chris Bieneman wrote: > > This is a really bad argument for large influential changes like this. Quite the contrary---anybody can participate and anybody can express their concerns, explain their goals, their workflow, etc. For a large influential changes like this, "zoning out" is a poor choice of action. > I suspect this is why the idea of having a

You are right. Regarding lanes i can comment only when the other things run fine. Here I am stuck with unsigned vs uint64_t. it looks as if i need to replace each occurrence of unsigned with uint64_t. Should i do it for complete llvm folder or codegen only?? i am continuously getting such errors which require changing unsigned with uint64_t. What to do now??? On Thu, Jul 20, 2017 at 1:03 AM,

On 7/27/2016 1:04 PM, James Molloy via llvm-dev wrote: > This thread is not particularly inviting. It has over 300 replies at the > time of writing and we don't all have the time to delve into such a > quagmire. That doesn't mean our opinions are worthless. It doesn't take reading all responses to see where the discussion is going. Important decisions take time to make.

Hi, Just to clarify I am looking for a whole machine function analysis not just something restricted to within a machine basic block. Thanks. Regards, Venu. From: Raghavan, Venugopal Sent: Saturday, September 02, 2017 12:56 PM To: llvm-dev at lists.llvm.org Subject: Reaching definitions on Machine IR post register allocation Hi, Given a definition of a register by a machine instruction in

On 4/28/2016 2:11 PM, Rail Shafigulin wrote: > > On Thu, Apr 28, 2016 at 6:13 AM, Krzysztof Parzyszek > <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote: > > > IIRC, > > What is IIRC? If I remember correctly... -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Hi All, I was looking into MachineCopyPropagationPass.ccp file in llvm, which in first look, looks likes to me doing only redundant copy elimination in same basic block. I am interested in any pass which is doing copy propogation across the basic block in a function. Let me know if any such pass exist ? Thanks, Deepali -------------- next part -------------- An HTML attachment was scrubbed...

On 3/16/2016 12:36 PM, Krzysztof Parzyszek via llvm-dev wrote: > If the action is "Expand", which will convert the operation into Unfinished edit. Should be If the action is "Expand", the legalizer will replace the operation with... -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

On X86, the registers AX, EAX and RAX all share the exact same register units. In terms of units, there is no difference between these registers. This makes register units insufficient to track liveness, since live AX does not imply live EAX. Would it make sense to have register units (and lane masks) for the parts of registers that are not individually addressable? -Krzysztof -- Qualcomm

On 1/7/2013 2:15 PM, Xu Liu wrote: > > This would be ideal. How can I do the instrumentation pass after the > instruction scheduling? You could derive your own class from TargetPassConfig, and add the annotation pass in YourDerivedTargetPassConfig::addPreEmitPass. This will add your annotation pass very late, just before the final code is emitted. If you're using the X86 target,

Enabling subreg liveness tracking didn't do anything. By altering the allocation order I managed to get the backend to use CL/CH for the struct, but the stores were still separate (even though storing CX would be correct)... Here's another question that falls into the same category: The function X86InstrInfo::loadRegFromStackSlot does not append any implicit uses/defs. How does it

On 5/30/2018 10:29 AM, Krzysztof Parzyszek via llvm-dev wrote: > For targets where ADDCARRY and SUBCARRY are legal, would it make sense > to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)? SelectionDAG will never generate ADDC/ADDE on targets where they aren't legal.  Targets which custom-lower ADDCARRY generally also custom-lower UADDO; not sure what sort of expansion

Yes, immediately after branch folding the code would still behave the same as the original. At the same time, any subsequent optimization may "exploit" the incorrect liveness information to do something bad. If you add -run-pass if-converter, you'll get: # After If Converter # Machine code for function fred: IsSSA, NoPHIs, TracksLiveness, NoVRegs BB#0: %R0<def>

Setting the MI as isTerminator should have the same impact, yes? I'm not sure of the other consequences of this though, if any, have to look into it. Thanks. -Ryan On Tue, Nov 15, 2016 at 5:18 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > You can override TargetInstrInfo::isSchedulingBoundary for that. > > -Krzysztof > > On 11/15/2016 4:13 PM, Ryan

I'm trying to see how the x86 backend deals with the relationship between AL, AH and AX, but I can't get it to generate any code that would expose an interesting scenario. For example, I wrote this piece: typedef struct { char x, y; } struct_t; struct_t z; struct_t foo(char *p) { struct_t s; s.x = *p++; s.y = *p; z = s; s.x++; return s; } But the output at -O2