Re: Caused by unknown alignment, was: Re: On the x86_64, does one have to zero a vector register before filling it completely ?
On Mon, Nov 30, 2009 at 12:10 PM, Steven Bosscher wrote: > I'll see if I can make the intraprocedural version work again before > Christmass. Well, it works, but then again it really does not. For example, the original implementation doesn't even look at the alignment of &var. So the pass doesn't do anything useful. Dan, do you have a copy somewhere that does more, or was that never implemented? Ciao! Steven
Re: CSE & compare/branch template problem
Joern Rennecke wrote: Quoting Michael Eager : Hi -- I'm working on creating the cstore and cbranch templates for the Xilinx MicroBlaze processor. In theory cstore / cbranch should be the future, but the last time I tried to use them, they didn't quite work right yet, particularily if you have an incomplete comparison set. Because of delays with the Copyright assignment, fixing the middle-end was not an efficient option, so I went for the old hack with separate compare and condjump / cstore patterns. Thanks. That's good to know. Somehow, CSE is deciding that reg 137 is equal to zero and translates insn 99 to (insn 99 98 100 3 .../strchr.c:93 (set (reg:CC 249) (eq:CC (reg:SI 247) (reg/v:SI 137 [ c+-3 ]))) 71 That is correct; after the jump_insn 94 is not taken, you can conclude that reg 137 is zero. Urk. After stepping through the code and seeing that the hw reg allocated to reg 137 was non-zero, I looked at the insns and (incorrectly) decided that CSE had been wrong. I think I managed to confuse myself since reg 246 is 1 if reg 137 is 0. This means that the instruction generated for the compare or the branch is incorrect. That's easier than chasing after a non-existent CSE bug. Thanks for pointing this out. Are there other targets which save comparison results in registers and require the condition? Yes. One example is SH64. Any suggestions on better ways to model the MicroBlaze comparison operations? Are there some restriction on using eq/ne/lt/... the way I am? Any suggestions on how to fix the problem in CSE? There are some problems if comparisons can't be reversed. I think it's a bug in the generic code, but for any given port, it's easier - and gives better code - to make sure that all conditions can be reversed, rather than fix the generic code. I ran into this with the MXP port. Thanks! -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Caused by unknown alignment, was: Re: On the x86_64, does one have to zero a vector register before filling it completely ?
On Sat, Dec 19, 2009 at 2:48 PM, Steven Bosscher wrote: > On Mon, Nov 30, 2009 at 12:10 PM, Steven Bosscher > wrote: >> I'll see if I can make the intraprocedural version work again before >> Christmass. > > Well, it works, but then again it really does not. For example, the > original implementation doesn't even look at the alignment of &var. > So > the pass doesn't do anything useful. Dan, do you have a copy somewhere > that does more, or was that never implemented? Yeah, somewhere, but honestly, i don't feel like digging it out.
Re: Caused by unknown alignment, was: Re: On the x86_64, does one have to zero a vector register before filling it completely ?
On Sat, Dec 19, 2009 at 11:43 PM, Daniel Berlin wrote: > On Sat, Dec 19, 2009 at 2:48 PM, Steven Bosscher > wrote: >> On Mon, Nov 30, 2009 at 12:10 PM, Steven Bosscher >> wrote: >>> I'll see if I can make the intraprocedural version work again before >>> Christmass. >> >> Well, it works, but then again it really does not. For example, the >> original implementation doesn't even look at the alignment of &var. > >> So >> the pass doesn't do anything useful. Dan, do you have a copy somewhere >> that does more, or was that never implemented? > Yeah, somewhere, but honestly, i don't feel like digging it out. OK, no problem. I'll see if I can come up with something myself. Ciao! Steven
