search for: __before__

...++CurrentTop, CurrentBottom); else { moveInstruction(MI, CurrentTop); TopRPTracker.setPos(MI); } ... But in moveInstruction we use // Update the instruction stream. BB->splice(InsertPos, BB, MI); And splice as far as I understand moves MI to the location right __before__ InsertPos. Our previous check made sure that InsertPos != MI, But I do hit a case, when MI == InsertPos--, and effectively tries to swap instruction with itself... which make live update mechanism very unhappy. If I am missing something in intended logic, please explain, otherwise it looks like w...

...moveInstruction(MI, CurrentTop); > TopRPTracker.setPos(MI); > } > ... > > But in moveInstruction we use > > // Update the instruction stream. > BB->splice(InsertPos, BB, MI); > > And splice as far as I understand moves MI to the location right __before__ > InsertPos. Our previous check made sure that InsertPos != MI, > But I do hit a case, when MI == InsertPos--, and effectively tries to swap > instruction with itself... which make live update mechanism very unhappy. > > If I am missing something in intended logic, please explain,...

...opRPTracker.setPos(MI); > > } > > ... > > > > But in moveInstruction we use > > > > // Update the instruction stream. > > BB->splice(InsertPos, BB, MI); > > > > And splice as far as I understand moves MI to the location right > > __before__ InsertPos. Our previous check made sure that InsertPos != > > MI, But I do hit a case, when MI == InsertPos--, and effectively > tries > > to swap instruction with itself... which make live update mechanism > very unhappy. > > > > If I am missing something in intended...

I couldn't compile any thing after upgrading 4.6.2 to 4.8 via cvsup I also updated ports via cvsup And nothing would compile, nothing, just error after error I cd /usr/ports did a -"make clean"- (which takes over an hour on my machine) Now all my compile problems have gone away I think I will cd to /usr/ports after doing anything with cvsup or any install, just in case or am I

...> > ... > > > > > > But in moveInstruction we use > > > > > > // Update the instruction stream. > > > BB->splice(InsertPos, BB, MI); > > > > > > And splice as far as I understand moves MI to the location right > > > __before__ InsertPos. Our previous check made sure that InsertPos != > > > MI, But I do hit a case, when MI == InsertPos--, and effectively > > tries > > > to swap instruction with itself... which make live update mechanism > > very unhappy. > > > > > > If I am...

...opRPTracker.setPos(MI); > > } > > ... > > > > But in moveInstruction we use > > > > // Update the instruction stream. > > BB->splice(InsertPos, BB, MI); > > > > And splice as far as I understand moves MI to the location right > > __before__ InsertPos. Our previous check made sure that InsertPos != > > MI, But I do hit a case, when MI == InsertPos--, and effectively > tries > > to swap instruction with itself... which make live update mechanism > very unhappy. > > > > If I am missing something in intended...

...> > ... > > > > > > But in moveInstruction we use > > > > > > // Update the instruction stream. > > > BB->splice(InsertPos, BB, MI); > > > > > > And splice as far as I understand moves MI to the location right > > > __before__ InsertPos. Our previous check made sure that InsertPos > != > > > MI, But I do hit a case, when MI == InsertPos--, and effectively > > tries > > > to swap instruction with itself... which make live update mechanism > > very unhappy. > > > > > > If...

...opRPTracker.setPos(MI); > > } > > ... > > > > But in moveInstruction we use > > > > // Update the instruction stream. > > BB->splice(InsertPos, BB, MI); > > > > And splice as far as I understand moves MI to the location right > > __before__ InsertPos. Our previous check made sure that InsertPos != > > MI, But I do hit a case, when MI == InsertPos--, and effectively > tries > > to swap instruction with itself... which make live update mechanism > very unhappy. > > > > If I am missing something in intended...

...; >> > > But in moveInstruction we use >> > > >> > > // Update the instruction stream. >> > > BB->splice(InsertPos, BB, MI); >> > > >> > > And splice as far as I understand moves MI to the location right >> > > __before__ InsertPos. Our previous check made sure that InsertPos >> != >> > > MI, But I do hit a case, when MI == InsertPos--, and effectively >> > tries >> > > to swap instruction with itself... which make live update mechanism >> > very unhappy. >> >...

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*

...veInstruction we use > >> > > > >> > > // Update the instruction stream. > >> > > BB->splice(InsertPos, BB, MI); > >> > > > >> > > And splice as far as I understand moves MI to the location right > >> > > __before__ InsertPos. Our previous check made sure that > InsertPos > >> != > >> > > MI, But I do hit a case, when MI == InsertPos--, and effectively > >> > tries > >> > > to swap instruction with itself... which make live update > >> > > me...

...> > ... > > > > > > But in moveInstruction we use > > > > > > // Update the instruction stream. > > > BB->splice(InsertPos, BB, MI); > > > > > > And splice as far as I understand moves MI to the location right > > > __before__ InsertPos. Our previous check made sure that InsertPos != > > > MI, But I do hit a case, when MI == InsertPos--, and effectively > > tries > > > to swap instruction with itself... which make live update mechanism > > very unhappy. > > > > > > If I am...

On Aug 13, 2012, at 8:34 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, > > Yes, this is what Arnold has suggested also, and from this point it looks > like it should work, but it will require parsing the bundle every time we > care to know whether this is a real use or a conditional def. This might > become awkward... but I guess I should provide a better

...recognize them would follow... but we had another thread on this topic not that long ago. So, IMHO the following would make sense: 1) It would be very nice if we can have some sort of write-up detailing proposed changes, and maybe defining overall strategy for instruction scheduling in LLVM __before__ major decisions are made. It should later be converted in to "how to" or simple doc chapter on porting scheduler(s) to new targets. Public discussion should follow, and we need to try to accommodate all needs (as much as possible). 2) Any attempts on my part to further VLIW scheduler de...

...ect/summarize requirements including abstract design goals but also concrete examples that should (not) be supported. => We will use the summaries to prepare a short presentation for the BoF (~10min) which allows us to use the majority of time for a qualified discussion on the topic. __Before__ we now dive into a technical discussion I would like people to provide feedback on the proposed structure first. This will (hopefully) allow a more organized and constructive discussion. Thanks, Johannes, Simon and Kevin *** All lists of references are incomplete. They provide a starting...

Sergei, I would say that each target has its own scheduling strategy that has changed considerably over time. We try to maximize code reuse across targets, but it's not easy and done ad hoc. The result is confusing code that makes it difficult to understand the strategy for any particular target. The right thing to do is: 1) Make it as easy as possible to understand how scheduling works for

...t;> is, the if-cascade<br>> checking the work function pointer is not there.<br>> <br>> Avoiding this potential performance decline is actually very easy. While we do<br>> not have the "inline_late" capability,<br>> run the openmp-opt pass __before__ the inliner and we will not get "worse"<br>> code. We might however miss out on<br>> _new_ non-SPMD -> SPMD transformations.<br>> <br>> <br>> Does that make sense?<br>> <br>> $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,...

Where we are ------------ Currently, when we generate OpenMP target offloading code for GPUs, we use sufficient syntactic criteria to decide between two execution modes: 1) SPMD -- All target threads (in an OpenMP team) run all the code. 2) "Guarded" -- The master thread (of an OpenMP team) runs the user code. If an OpenMP distribute region is encountered,