This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, Jun 17, 2009 at 8:36 AM, H.J. Lu<hjl.tools@gmail.com> wrote:I would recommend against until someone has done a real analysis of the problem. Once that analysis is done we can weigh the correct fix vs the hack in terms of performance and potential for introducing regressions.
On Wed, Jun 17, 2009 at 8:22 AM, Jeff Law<law@redhat.com> wrote:
Steven Bosscher wrote:I am all for it. Vladimir, how hard to fix RA for this?
On 6/17/09, Jeff Law <law@redhat.com> wrote:It'll completely disable the RTL loop optimizers. Granted this is less
Richard Guenther wrote:
On Wed, Jun 17, 2009 at 4:01 PM, H.J. Lu<hongjiu.lu@intel.com> wrote:Agreed. In fact, it can have horrific performance impacts.
Hi,
Some SSE4 instructions have implicit XMM0 operand. This patch helps RA deal with them by forcing operand into XMM0 during expand. OK for trunk and 4.4?
I don't think it's a particularly good idea to put things in hardregs that early.
Why? Most optimizazions that can be done for this insn can only be done on GIMPLE, right? And the insn must have that specific register. So unless I am missing something, I don't see why this patch would do any harm.
important today than before, but it's still bad. And more importantly, the
register allocators and reload should be fixed to DTRT rather than hacking
around them.
This fails in gcc 4.3/4.4/4.5. Fixing RA/reload sounds good for
4.5. Is that a good idea for 4.4, especially for 4.3? Can I apply
my patch to 4.3 first?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |