Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
When compiling something like
#define O +
long x4(long x, long a, long b, long c, long d) { return x O a O b O c O d; }
we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #29 from Segher Boessenkool ---
(In reply to Richard Biener from comment #26)
> So it would need to be diagnosed in the FE (only), making a + 0 valid and
> a not. Eh.
We do not *have* to diagnose anything, certainly not things that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #28 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #25)
> Even if we wanted to do something about it (which I disagree with, e.g.
> given that the implementation matches the documentation), you run into the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #27 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #24)
> Segher, did you really mean to mark the bug resolved/fixed?
No, if I did that, I have no idea how :-)
> Given that the only supported use of local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #23 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #21 from Segher Boessenkool ---
register float foo asm ("xmm0") = 0.99f;
asm volatile("movl %0, %%r8d\n\t"
"vmcall\n\t"
:: "g" (foo));
The user said operands[0] should go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #19 from Segher Boessenkool ---
Documenting that GCC behaves differently is just documenting a bug :-(
It should not be hard to detect this and give an error somewhere?
Saying "the user did something wrong" is true of course, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
iority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
See https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557759.html and
the thread leading up to it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #9 from Segher Boessenkool ---
Yes, that looks correct.
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
This leads to errors at compiler runtime instead of at compiler build time.
See https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556998.html .
Code from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #3 from Segher Boessenkool ---
This part of the attribute (all but the low 2 bits) is not documented
in the as manual, btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #31 from Segher Boessenkool ---
Performing a jump based on the carry bit is not something we can
easily do (there are no simple insns for it, and those sequences
that will do the trick are expensive). But I'll look at that,
thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #29 from Segher Boessenkool ---
Yup, and that is a more elegant way of writing this anyway. But we
still do not handle the exact testcase code optimally ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #46 from Segher Boessenkool ---
(In reply to Christophe Leroy from comment #43)
> int g(int x)
> {
> return __builtin_clz(0);
> }
>
> Gives
>
> 0018 :
> 18: 38 60 00 20 li r3,32
> 1c: 4e 80 00 20 blr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #35 from Segher Boessenkool ---
Send it to gcc-patches@ please, with explanation and everything?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #26 from Segher Boessenkool ---
It isn't easy to do. Feel free to try your hand at it :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #31 from Segher Boessenkool ---
(In reply to Jan Hubicka from comment #27)
> It is because --param inline-insns-single was reduced for -O2 from 200
> to 70. GCC 10 has newly different set of parameters for -O2 and -O3 and
> enables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94761
--- Comment #3 from Segher Boessenkool ---
Commit e69bf64be925 added the host and target flags originally, and it
seems to have been just a mistake that is used --build=${build_alias}
--host=${build_alias}. (Now of course that has spread to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94761
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97437
--- Comment #10 from Segher Boessenkool ---
Not even an alternative SELECT_CC_MODE; just add an argument to it, giving
the original mode? We already have that in combine, so we can trivially
pass it. Will that work for x86 here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97437
--- Comment #8 from Segher Boessenkool ---
So is that something than can/should be improved in ix86_cc_mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97437
--- Comment #6 from Segher Boessenkool ---
I forgot to add: subtract immediate is the same as add immediate for us,
we don't change the sense of the carry bit to a "borrow bit" (and instead,
we have a subtract-from-immediate). But this doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97437
--- Comment #5 from Segher Boessenkool ---
Trying 7 -> 9:
7: r97:SI=0x2a
9: {flags:CCC=cmp(r97:SI+r98:SI,r97:SI);r99:SI=r97:SI+r98:SI;}
REG_DEAD r98:SI
REG_DEAD r97:SI
Failed to match this instruction:
(parallel [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97249
--- Comment #5 from Segher Boessenkool ---
(In reply to Richard Biener from comment #3)
> Guess you want to figure what built the (vec_select:V8QI (V16QI)) and if
> it was appropriately simplified (and simplify_rtx would handle this case).
> In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #8 from Segher Boessenkool ---
The default -mcpu= for a compiler targeting powerpc64le-linux is
normally power8 (you can change this with the --with-cpu= configure
option though). -mcpu=powerpc64le is also (currently) equal to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #5 from Segher Boessenkool ---
So both the cache line size and the cache size are wrong for GCC 10
and before, but okay on trunk, on all compiler I tested (I tested on
Linux only so far).
|1
Status|UNCONFIRMED |NEW
CC||segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool ---
At least as far back as GCC 5 we report D-L1 size 64kB (for most CPUs,
not just p9). Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97163
--- Comment #7 from Segher Boessenkool ---
Ah.
Is there no better way to detect GCC impostors? Oh well.
Since we require 4.5 as bootstrap compiler, this makes no difference
at all for compilers that truthfully claim to be GCC, so it has my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97163
--- Comment #5 from Segher Boessenkool ---
Yeah, good point.
So either we can convert to the normal intrinsics, or (much easier)
check we are building with GCC at all. But why 4.5? Do earlier
versions not work?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97163
--- Comment #3 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #2)
> Guess we need something like:
> -#elif defined(_ARCH_PWR8) && defined(__ALTIVEC__)
> +#elif (GCC_VERSION >= 4005) && defined(_ARCH_PWR8) &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #8 from Segher Boessenkool ---
I don't think we have an instruction for that? But we can inline the
code we need instead of doing a library call, which is much faster.
(We probably can use FMAs here usefully, btw; maybe even without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #16 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #15)
> Fixed.
Yes. Thanks!
|NEW
CC||segher at gcc dot gnu.org
Last reconfirmed||2020-09-16
--- Comment #6 from Segher Boessenkool ---
Confirmed.
Maaybe cse2 should do this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-09-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
--- Comment #8 from Segher Boessenkool ---
(In reply to Alan Modra from comment #7)
> and of course, li 0x is li -1 which sets all bits.
Erm, yes. Duh.
So that g:5d3ae76af13 splitter should not fire for numbers that fit in
32 bits but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #26 from Segher Boessenkool ---
What Joseph says in c#25. Also, the documentation currently says
The @code{KIND} value matches the storage size in bytes, [...]
which will have to change, too (the standard does not require this,
it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
--- Comment #5 from Segher Boessenkool ---
So hrm, why did GCC generate lis 0x ; ori 0x ; rldicl instead of
li 0x ; oris 0x ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #20 from Segher Boessenkool ---
Could you guys please test the attached patch? Thanks in advance!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #19 from Segher Boessenkool ---
Created attachment 49215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49215=edit
proposed patch for the ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
Segher Boessenkool changed:
What|Removed |Added
Attachment #49214|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
--- Comment #3 from Segher Boessenkool ---
Created attachment 49214
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49214=edit
proposed patch for the ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #18 from Segher Boessenkool ---
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #20 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #18)
> > Why aren't KFmode, IFmode and TFmode all 128??? Mike?
>
> This comes from rs6000-modes.h:
>
> /* We order the 3 128-bit floating point types so that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97019
--- Comment #1 from Segher Boessenkool ---
Cool, if that helps, great!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #12 from Segher Boessenkool ---
Thanks. Unfortunately it isn't saying much more (well, during which
pass this happened, pretty important ;-) )
> I can prepare the preprocessed source tomorrow if needed.
Thanks! That will make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #10 from Segher Boessenkool ---
Please show the full message? (It starts with "internal compiler error".)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96965
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #9 from Segher Boessenkool ---
I'm not sure what you mean.
vmrglb merges the vectors
abcdefghijklmnop
and
ABCDEFGHIJKLMNOP
to
iIjJkKlLmMnNoOpP
... ah, I see what you mean I guess.
So, use something else instead? How about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #7 from Segher Boessenkool ---
There are vmrglb and vrghb etc.?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830
--- Comment #10 from Segher Boessenkool ---
Thanks Carl!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #4 from Segher Boessenkool ---
Yes, timing suggests there is some SHL/LHS flush.
On p9 and later we can use mtvsrdd instead of mtvsrd (moving two
bytes into place at one), which reduces the number of moves from
16 to 8, and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #1 from Segher Boessenkool ---
Is that actually faster though? The original has shorter dependency
chains. Or is this to avoid some LHS/SHL?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96786
--- Comment #1 from Segher Boessenkool ---
Perhaps we should just ignore AltiVec for the .machine selection?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96786
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
Reported by Sergei in
https://sourceware.org/bugzilla/show_bug.cgi?id=26522
This happens since gcc.gnu.org/g:2d94f7dea9c7 (but that is just what
triggered
Assignee: dmalcolm at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
On powerpc64-linux.
For -m32:
+FAIL: gcc.dg/analyzer/init.c (test for warnings, line 100)
+FAIL: gcc.dg/analyzer/init.c (test for warnings, line 101)
+FAIL: gcc.dg/analyzer/init.c (test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #6 from Segher Boessenkool ---
I have a patch (since yesterday; just no time to send it :-/ )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #4 from Segher Boessenkool ---
https://gcc.gnu.org/g:1f9ceff11132
-ftree-coalesce-vars it sounds like? But that isn't a 1-1 replacement
probably (or, what was the point of this change otherwise?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #2 from Segher Boessenkool ---
That option was removed in GCC 6, already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96446
--- Comment #2 from Segher Boessenkool ---
*movpxi tries to not split xxsetaccz insns, but that one is only for
fpr_reg_operand as operands[0], while *movpxi uses something more
general.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96343
--- Comment #3 from Segher Boessenkool ---
Thanks for the report.
Yes, not sure we can reproduce it like this. We might need something
smaller, more self-contained.
In the meantime... Can you check if this still happens with trunk,
or with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96298
Segher Boessenkool changed:
What|Removed |Added
Assignee|segher at gcc dot gnu.org |sayle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96298
--- Comment #5 from Segher Boessenkool ---
Trying 17, 14 -> 18:
17: r147:DI=r145:DI^r121:DI
REG_DEAD r145:DI
REG_DEAD r121:DI
14: r144:DI=r142:DI^r121:DI
REG_DEAD r142:DI
18: r148:DI=r144:DI^r147:DI
REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96298
--- Comment #3 from Segher Boessenkool ---
It doesn't fail with 9.3 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #6 from Segher Boessenkool ---
(So, pre-approved with that change, and with a testcase... A run test
ideally, if that isn't too hard?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
--- Comment #5 from Segher Boessenkool ---
operands[2] needs an earlyclobber as well (it is written while some
operands are still read later). Everything else is fine as far as I
can see :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #14 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
--- Comment #6 from Segher Boessenkool ---
It certainly would be nice to improve this :-) It won't help most code
very much -- how often do two-word values happen at all -- but we have
to revisit how all this is decided anyway (for prefixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Bug 94042 depends on bug 94148, which changed state.
Bug 94148 Summary: The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95581
--- Comment #12 from Segher Boessenkool ---
This is pre-approved with a testcase (if it fixes that testcase, etc.,
yadda yadda).
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
--- Comment #7 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #6)
> rldicr is one of the insns generated by "*rotl3_mask", which
> recognises all canonical formulations of all our rotate-and-mask
> instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #11 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #9)
> (In reply to Peter Bergner from comment #8)
> > At first, I thought that split_live_ranges_for_shrink_wrap() split this
> > nicely, but what I found is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #10 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #6)
> Right, that's why we need to add the copies before RA, so we don't have to
> look for unused regs. But we don't want to add the copies too early just
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-07-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
--- Comment #6 from Segher Boessenkool ---
rldicr is one of the insns generated by "*rotl3_mask", which
recognises all canonical formulations of all our rotate-and-mask
instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #4 from Segher Boessenkool ---
Or even just { target le } yes. You can put that as the selector on just
the scan tests, and even do a separate BE version as well.
You can quote regexps with {} instead of "", that makes them much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907
--- Comment #1 from Segher Boessenkool ---
Confirmed (in C, with _Bool).
This is yet another case of enabling some insns but disabling many other
insns: our power10 support requires insns we enable on power9 and later
only (set[n]bc[r] is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
--- Comment #4 from Segher Boessenkool ---
Maybe you can make a define_insn_and_split for the lshrdi3 plus this?
Which will split to an insn fewer immediately.
If you split after reload you need many extra patterns to get the most
basic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87600
--- Comment #9 from Segher Boessenkool ---
(In reply to Alexandre Oliva from comment #8)
> I've noticed regressions caused by make_more_copies, in scenarios that used
> subreg s for the low part of promoted incoming parms. With hard regs, the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704
--- Comment #6 from Segher Boessenkool ---
13 insns, but the longest chain is 4. As I said, not totally awful, and
much better than the branchy code (which does not predict well, for more
general inputs anyway).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704
--- Comment #4 from Segher Boessenkool ---
It no longer generates that rldicl in GCC 9 (or GCC 10).
You do get straight-line code already if you use -mcpu=power9, btw
(isel; and not totally awful code, but it isn't super of course).
|1
CC||segher at gcc dot gnu.org
Last reconfirmed||2020-06-17
--- Comment #2 from Segher Boessenkool ---
(In reply to Jens Seifert from comment #0)
> PowerPC processors don't like branches and bra
||2020-06-10
Target|powerpc-*-*-* |powerpc*-*-*
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
Interesting! I tried it out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95469
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95581
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95531
--- Comment #6 from Segher Boessenkool ---
There is also SELECT_CC_MODE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95531
--- Comment #5 from Segher Boessenkool ---
Various things can change the comparison mode. simplify_compare_const
is the most prominent example (hrm, maybe the only one now?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158
--- Comment #11 from Segher Boessenkool ---
Do you have a reproducer you can share?
I'll happily reopen the PR then, of course!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68837
--- Comment #4 from Segher Boessenkool ---
On Power9 the lwa insn is cracked into an lwz and an extsw, just like
on older CPUs. Cracked instructions have fewer constraints on p9 than
they did on most older CPUs though (it doesn't have to be
801 - 900 of 3161 matches
Mail list logo
