http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
H.J. Lu changed:
What|Removed |Added
Attachment #25042|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
H.J. Lu changed:
What|Removed |Added
Attachment #25040|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
H.J. Lu changed:
What|Removed |Added
Attachment #25025|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #17 from Richard Guenther 2011-08-17
14:42:11 UTC ---
(In reply to comment #16)
> The testcase has ...
>
> int n8 = (arr[7] * 9 + 8) & 15;
>
> for (i = 0; i < len; i+=8)
> {
> n1 = (n1 + 1) & 15;
>
> s += arr[i]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #16 from H.J. Lu 2011-08-17 14:37:35
UTC ---
The testcase has ...
int n8 = (arr[7] * 9 + 8) & 15;
for (i = 0; i < len; i+=8)
{
n1 = (n1 + 1) & 15;
s += arr[i] << n1;
The shift count is 32bit, which causes 32bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #15 from Ilya Enkovich 2011-08-17
14:16:27 UTC ---
(In reply to comment #14)
>
> I think this problem is unique to x86 since some instructions have
> different sizes in register operands. In this example, shift count
> is CL regardl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #14 from H.J. Lu 2011-08-17 13:37:39
UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > Created attachment 25025 [details]
> > A patch to use the same mode for shift count
> >
> > This is an untested patch to use the s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #13 from Ilya Enkovich 2011-08-17
09:07:20 UTC ---
(In reply to comment #12)
> Created attachment 25025 [details]
> A patch to use the same mode for shift count
>
> This is an untested patch to use the same mode for shift count.
We
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
H.J. Lu changed:
What|Removed |Added
Attachment #25019|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #11 from H.J. Lu 2011-08-16 14:45:27
UTC ---
Can we model shift instructions to take any QI/HI/SI/DI register
as shift count and make IRA to match the size when reading/writing
shift count?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #10 from H.J. Lu 2011-08-16 14:23:39
UTC ---
The real problem is the store forward issue on Atom:
addl$1, 4(%esp) # 67*addsi_1/2 [length = 5]
andl$15, 4(%esp)# 68*andsi_1/1 [length =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #9 from Ilya Enkovich 2011-08-16
07:28:33 UTC ---
(In reply to comment #5)
>
> It is for movqi. We can only safely replace mozbl with movl if
> the source is 4byte aligned. It should a new backend option.
That should work.
A bet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #8 from Ilya Enkovich 2011-08-16
06:55:34 UTC ---
(In reply to comment #4)
>
> Well, yes, I think the proposal was to spill/load the full SImode instead
> which would avoid both the partial dependency and the mismatched load/store
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #6 from H.J. Lu 2011-08-15 17:19:22
UTC ---
Created attachment 25019
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25019
A patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #5 from H.J. Lu 2011-08-15 15:47:39
UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > It is done on purpose:
> >
> > /* X86_TUNE_MOVX: Enable to zero extend integer registers to avoid
> > partial dependencies. *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #4 from Richard Guenther 2011-08-15
15:26:19 UTC ---
(In reply to comment #3)
> It is done on purpose:
>
> /* X86_TUNE_MOVX: Enable to zero extend integer registers to avoid
> partial dependencies. */
> m_PPRO | m_P4_NOCONA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #2 from Ilya Enkovich 2011-08-15
13:24:05 UTC ---
Actually we do not need any zero extensions here. Zero extended load appears
only after IRA if we have to spill/fill register.
Here is c code from reproducer:
n1 = (n1 + 1) & 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #1 from Richard Guenther 2011-08-15
13:07:50 UTC ---
I don't think we know at this point that the data is already properly
zero-extended.
20 matches
Mail list logo
