->1 combination
already, if it is beneficial: both 18->7 and 7->22 should have combined
just fine. This also points to a potential target problem: why are those
two combinations not allowed?
Segher
trunk arm
has non-optimal code for addH0, addSH, addB1, addB8, addSH42, addSHm1, and
addSHff if I understand well enough. So I'd love to see what it does with
your series applied :-)
Segher
On Sun, Oct 20, 2019 at 12:21:21PM +0100, Richard Earnshaw (lists) wrote:
> On 19/10/2019 17:31, Segher Boessenkool wrote:
> > I have a bunch of testcases from when I did something similar for PowerPC
> > that I wanted to test... But I cannot get your series to apply. Do you
>
that's alright. The instructions as-is are a good
habit to get into, and for more advanced things you *do* need to name your
remote and branches; you'll have to learn them some time, why not now.
Both commands are fine, if you have your changes on local master.
However. *Never ever* use "git push -f". Don't drive without safety belts.
(Use "+" when you want to force push a branch, don't force push the world).
Segher
o this
> > version of the patch just replaces the can_create_pseudo_p () conditions
> > with a new predicate that stops matching already after the split1 pass.
>
> As explained by Segher in the PR, there is no 100% guarantee that
> combine won't produce a pattern with a wr
On Mon, Oct 21, 2019 at 01:27:23PM +0200, Jakub Jelinek wrote:
> On Mon, Oct 21, 2019 at 05:45:16AM -0500, Segher Boessenkool wrote:
> > On Sun, Oct 20, 2019 at 09:51:22PM +0200, Uros Bizjak wrote:
> > > On Sun, Oct 20, 2019 at 1:24 PM Jakub Jelinek wrote:
> > > > A
On Mon, Oct 21, 2019 at 03:46:53PM +0100, Richard Earnshaw (lists) wrote:
> On 19/10/2019 14:00, Segher Boessenkool wrote:
> >On Fri, Oct 18, 2019 at 08:48:40PM +0100, Richard Earnshaw wrote:
> >>
> >>The cost routine for Arm and Thumb2 was not recognising the idioms tha
On Mon, Oct 21, 2019 at 08:20:33AM -0700, Mike Stump wrote:
> On Oct 21, 2019, at 3:30 AM, Segher Boessenkool
> wrote:
> >
> > On Sun, Oct 20, 2019 at 06:06:30PM +0200, Gerald Pfeifer wrote:
> >> On Wed, 9 Oct 2019, js...@gcc.gnu.org wrote:
> >>>
On Mon, Oct 21, 2019 at 05:06:20PM +0100, Richard Earnshaw (lists) wrote:
> On 21/10/2019 16:46, Segher Boessenkool wrote:
> >>>There also is the insn_cost hook, which especially for RISC-like targets
> >>>is a lot easier to define.
> >>
> >>Easier, but
On Mon, Oct 21, 2019 at 04:46:47PM +0100, Richard Earnshaw (lists) wrote:
> On 19/10/2019 17:17, Segher Boessenkool wrote:
> >Maybe we should simply disallow pseudo-to-pseudo (or even all) copies when
> >combining more than two insns, always? I'll experiment.
> For the 2-i
Hi!
On Tue, May 05, 2020 at 08:41:35PM -0400, Hans-Peter Nilsson wrote:
> On Fri, 1 May 2020, Segher Boessenkool wrote:
> > On Mon, Apr 27, 2020 at 05:01:34PM -0500, will schmidt wrote:
> > > On Mon, 2020-04-27 at 15:53 -0400, Michael Meissner via Gcc-patches wrote:
>
his patch fixes the combiner to punt in that case,
> because otherwise
> the auto-inc-dec side-effects from the SET_SRC are lost.
>
> Bootstrapped/regtested on {x86_64,i686,aarch64,powerpc64{,le}}-linux,
> preapproved in the PR by Segher, committed to trunk so far.
Thanks! It wo
d have done this part as a separate
patch, it looks much more involved than it actually is now.
Segher
me. But maybe David can find something? :-)
Thank you for handling this!
Segher
> >Bill Schmidt (4):
> > Add insns for setbc and setbcr
> > Add tests for setbc and setbcr
> > Add insns for setnbc and setnbcr
> > Add tests for setnbc and setnbcr
(I assu
tion/octet-stream isn't
> > something I can reply to. Just text/plain is fine :-)
>
> I have using plain text now, hope that works for you. :-)
It is still application/octet-stream.
Segher
r gcc.target/powerpc. Just "dg-do
compile" is fine, which sometimes is good documentation, but even that
is the default :-)
Looks fine to me otherwise.
Segher
eally matter of
course.
(This needs an unspec because it isn't viable to describe in RTL what
this op does -- it is not an AND with the mask and then a count, the
masked-out bits are actually skipped for the count).
Looks fine to me, thanks,
Segher
(define_c_enum "unspec"
> UNSPEC_VRLNM
> UNSPEC_VCLZDM
> UNSPEC_VCTZDM
> + UNSPEC_VPDEPD
> + UNSPEC_VPEXTD
Similarly, maybe UNSPEC_PDEP and UNSPEC_PEXT would be nicer.
Looks okay for trunk either way :-)
Segher
for master?
This one looks fine as well. All (up to here ;-) ) are okay for trunk,
unless David sees something (I have seen these patches too often before
already, that causes blind spots :-) ) Thanks!
Segher
this okay for master?
Yes, this one is fine as well. Thank you,
Segher
> 2020-05-08 Kelvin Nilsen
>
> * config/rs6000/rs6000-builtin.def (__builtin_pdepd): New built-in
> function.
> (__builtin_pextd): Likewise.
> * config/rs6000
fine to me as well. We could drop the "D" from the unspec
name, the size is in the mode already, but let's leave that to a future
cleanup :-)
Segher
r master?
Yup, looks fine. Thanks,
Segher
RGET_64BIT"
> + "cntlzdm %0,%1,%2"
> + [(set_attr "type" "integer")])
TARGET_POWERPC64.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/cntlzdm-0.c
> @@ -0,0 +1,57 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target lp64 } */
And powerpc64 here as well then.
Not sure if this is a bigger problem than the comma thing though.
Segher
s is okay. Thanks!
Segher
the insn.
But, in this case, you *do* call the insn directly (namely, from the
define expand!) So maybe use a "xxgenpcvm_internal" or similar
name for the define_insn?
Okay for trunk with that improved somehow. Thanks!
Segher
Hi!
On Sat, May 09, 2020 at 01:15:44PM -0400, David Edelsohn wrote:
> Okay with those changes, plus any issues noticed by Segher.
The only thing I can add is, I hope Bill's builtin work will make it
unnecessary to also define QUINARY and SENARY macros (yes I looked it
up), before we ne
ity with unsigned SImode rather than unsigned QImode.
Is it still checked for range 0..255 though? (If the compiler can
derive that).
In either case, if that is what the ABI says, that is what the ABI says,
so okay for trunk.
Thanks!
Segher
On Mon, May 11, 2020 at 09:31:41PM -0500, Bill Schmidt wrote:
> On 5/11/20 7:16 AM, Segher Boessenkool wrote:
> >>* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
> >>Change fourth operand for vec_ternarylogic to require
> >>compatibili
> +emit_insn (gen_vstril_p_code_ (scratch, operands[1]));
> + emit_insn (gen_cr6_test_for_zero (operands[0]));
> + DONE;
> +})
And the code for the builtin can do this then, as well.
Not sure how easy that is to fit in with the current code, or after your
work on it. Either way, it looks fine to me :-)
Segher
On Mon, May 11, 2020 at 11:45:09AM -0500, Bill Schmidt wrote:
> On 5/8/20 6:51 PM, Segher Boessenkool wrote:
> >On Fri, May 08, 2020 at 08:17:18AM -0500, Bill Schmidt wrote:
> >>From: Kelvin Nilsen
> >>
> >>Add support for new scalar instructions for counting
re selective ;-) (And, document what it doesn't want to
see, if it isn't really obvious?)
Segher
the word "extract", and create similar iterators for the
> vstril/vstrir patterns; or (2) remove the iterators from this patch and
> just create two expansions and two insns instead of one of each. I have
> a slight preference for (2) since the longer iterator names will make
ped and tested on powerpc64le-unknown-linux-gnu with no
> regressions, using a Power9 configuration. Is this okay for
> master?
This is okay for trunk. Thanks!
Segher
> 2020-05-12 Kelvin Nilsen
>
> * config/rs6000/altivec.h (vec_extractl): New #define.
>
on for
> first_match_index_.
> * testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c (main): Add
> additional test cases with zero vector elements.
Okay for trunk and all backports needed after a while. Thanks!
Segher
Tests that use the __int128 type need to use the int128 selector.
2020-05-15 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/vec-gnb-0.c: Use int128 effective target.
* gcc.target/powerpc/vec-gnb-1.c: Ditto.
* gcc.target/powerpc/vec-gnb-2.c: Ditto
2020-05-15 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/cnttzdm-0.c: Use lp64.
---
gcc/testsuite/gcc.target/powerpc/cnttzdm-0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.target/powerpc/cnttzdm-0.c
b/gcc/testsuite/gcc.target/powerpc/cnttzdm-0.c
Some fixes for -mcpu=future, mostly testsuite. This also cleans up
some other testsuite problems.
Tested on powerpc64-linux {-m32,-m64}; committing to trunk. This
hopefully cleans up some of the AIX problems here as well.
Segher
Segher Boessenkool (5):
rs6000/testsuite: Use -mdejagnu-cpu
The powerpc64 effective target unfortunately does not mean the target
has 64-bit instructions enabled (i.e., -mpowerpc64): instead, it means
that the assembler supports it.
Let's use the lp64 effective target instead for these tests.
2020-05-15 Segher Boessenkool
gcc/test
A bunch of new cases snuck in.
2020-05-15 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/pdep-0.c: Change -mcpu= to -mdejagnu-cpu=.
* gcc.target/powerpc/pdep-1.c: Ditto.
* gcc.target/powerpc/pextd-0.c: Ditto.
* gcc.target/powerpc/pextd-1.c: Ditto
BU_FUTURE_MISC_2 is (currently) only used for instructions that require
64-bit registers.
2020-05-15 Segher Boessenkool
* config/rs6000/rs6000-builtin.def (BU_FUTURE_MISC_2): Also require
RS6000_BTM_POWERPC64.
---
gcc/config/rs6000/rs6000-builtin.def | 3 ++-
1 file changed
Hi!
On Sat, May 16, 2020 at 09:46:15AM -0500, Peter Bergner wrote:
> On 5/13/20 11:22 AM, Joel Brobecker wrote:
> > Would someone mind reviewing this patch, please?
> You should always CC the PPC maintainers on PPC patches.
> I've CC'd both Segher and David.
Thanks P
Hi!
On Mon, May 18, 2020 at 11:54:31AM -0700, Joel Brobecker wrote:
> > (Don't forget the changelog?)
>
> Thank you, Segher. Pushed to master, and for 8, 9 and 10.
Thanks!
> I did include the ChangeLog indeed. I tend to avoid sending them
> in the diff, because they usu
merely
tests if the assembler can handle VSX at all. If you use GNU binutils
at least, you are supposed to use one that isn't much older than the
GCC you are using (on other platforms the user cannot always easily
get a fully working assembler and linker :-/ )
So what are you seeing without this patch?
Segher
On Tue, May 19, 2020 at 02:41:45PM -0700, Douglas B Rupp wrote:
>
> On 5/19/20 1:53 PM, Segher Boessenkool wrote:
> >How can altivec not be supported when you use -mcpu=power8?
> >
> For the test in question: builtins-1-be-folded.c:
>
> The VxWorks header file altivec.
Hi~
On Tue, May 19, 2020 at 03:20:37PM -0700, Douglas B Rupp wrote:
> On 5/19/20 3:03 PM, Segher Boessenkool wrote:
> >This is a compile test, so it does not matter at all what the kernel is
> >doing or not doing. And the -mcpu=power8 flag should enable altivec.
> >Apparent
&& !(TREE_CODE (niter) == INTEGER_CST
&& single_exit (loop)
&& num_stmt_in_loop (loop) < 24))
(also keep the single_exit test first, it is a simpler thing, in code
executed but conceptually as well).
Looks fine then.
Segher
roller, and has been since forever.
Segher
ns, I'll have to dig a bit more to give an answer.
Well, kernel only matters for run tests (normally :-) ), and those
should already be skipped for you.
I'll do the backport. Thanks for getting to the bottom of this!
Segher
Hi!
On Thu, May 21, 2020 at 03:29:49PM +0200, Martin Liška wrote:
> Adding Segher to CC, he can help us.
Oh dear. Are you sure?
> On 5/21/20 2:51 PM, Martin Liška wrote:
> >Back to this I noticed that ppc64le target build is broken due to:
> >insn-emit.o -MMD -MP -MF ./.
On Fri, May 22, 2020 at 01:22:10PM +0200, Richard Biener wrote:
> On Wed, May 20, 2020 at 10:37 PM Segher Boessenkool
> wrote:
> >
> > On Wed, May 20, 2020 at 12:30:30PM +0200, Richard Biener wrote:
> > > I think this is the wrong way to approach this. You're doi
u do not pass "false" for that new bool argument, btw.,
which illustrates my point here.
Do we really want function calls that are indented fifty characters, and
then have nine(!) arguments? At some point adding stuff on top makes
things topple over, and it is better to restructure things first. Of
course that isn't fair to demand of you here, but maybe you see some
opportunity to improve things?
Segher
you. :-)
Nope:
[-- Attachment #2: pr94026-v2.diff --]
[-- Type: application/octet-stream, Encoding: base64, Size: 5.9K --]
Segher
dden and much more surprising.
Those functions really should take rtx_mode_t arguments?
Thanks again for working on this,
Segher
tl-combine" } */
> +
> +int
> +foo (int c)
> +{
> + int a = (c >> 8) & 7;
> +
> + if (a >= 2) {
> +return 1;
> + }
> +
> + return 0;
> +}
> +
> +/* The combine phase should transform (compare (and (lshiftrt x 8) 6) 0)
> + to (compare (and (x 1536)) 0). We look for the *attempt* to match this
> + RTL pattern, regardless of whether an actual insn may be found on the
> + platform. */
> +
> +/* { dg-final { scan-rtl-dump "\\(const_int 1536" "combine" } } */
That is a very fragile test.
Segher
gned_p.
> > > (emit_library_call_value): Added default arg unsigned_p.
> >
> > Yeah, eww. Default arguments have all the problems you had before,
> > except now it is hidden and much more surprising.
> >
> > Those functions really should take rtx_mode_t arguments?
>
> I was thinking the same. will incorporate this.
Thanks!
Segher
g.
Adding names like "rtl-unroll-loops" only stands in the way of getting
a better design here.
Segher
On Mon, May 25, 2020 at 02:39:54PM +0200, Richard Biener wrote:
> On Fri, May 22, 2020 at 6:54 PM Segher Boessenkool
> wrote:
> > > The split above allows the "bug" to be fixed (even on the branch)
> > > without introducing even more target specialities.
> >
>
> Feel free to ignore the regression part on the branch and come up with a
> great design. But don't expect to backport that then.
I just do not think fixing the regression should make things worse for
a long time, if that can be avoided.
Segher
to match this
> > > + RTL pattern, regardless of whether an actual insn may be found on the
> > > + platform. */
> > > +
> > > +/* { dg-final { scan-rtl-dump "\\(const_int 1536" "combine" } } */
> >
> > That is a very fragile test.
>
> For this specific test case, (const_int 1536) is calculated from
> subexpression (M << C) in (X & (M << C)).
> I also see some similar checkings in gcc.dg/asr_div1.c. Suggesions?
Maybe it is better to test that the non-optimal code you saw before is
not generated anymore? That could be a target-specific test of course.
The advantage is that the test will not break for all kinds of unrelated
reasons (like this test) -- that simply does not scale with the number
of tests we have.
Segher
Hi!
On Tue, May 26, 2020 at 08:58:13AM +0200, Richard Biener wrote:
> On Mon, May 25, 2020 at 7:44 PM Segher Boessenkool
> wrote:
> > Yes, cunroll does not have its own option, and that is a problem. But
> > that is easy to fix! Either with an option, or just with para
t much about it yet...
Or maybe only support 0..N with N the length of the vector? It is
pretty important to support 0 and N, but greater than N isn't as
important (it is useful for tricky hand-written code, but not as much
for compiler-generate code -- we only support an 8-bit number here on
Power, maybe that is why ;-) )
Segher
On Wed, May 27, 2020 at 09:25:43AM +0200, Richard Biener wrote:
> On Tue, 26 May 2020, Segher Boessenkool wrote:
> > On Tue, May 26, 2020 at 01:29:30PM +0100, Richard Sandiford wrote:
> > > FWIW, I agree adding .LEN_LOAD and .LEN_STORE seems like a good
> > > appro
y
> funroll-all-loops so you could simplify the above.
But only do that on trunk?
Segher
olling
> bases?
>
> I really hate to explode the number of options users have to
> consider optimizing their code ...
Well, the defaults should be good for almost everyone. But after that,
sure, it should be possible to tune things in a reasonable way.
> So if we can defer all this thinking and make a non-option flag
> variable work that would be best IMHO.
:-)
Segher
Hi Jiufu,
On Thu, May 28, 2020 at 04:52:07PM +0800, guojiufu wrote:
> gcc/ChangeLog
> 2020-02-28 Jiufu Guo
>
> PR target/95018
> * config/rs6000/rs6000.c (rs6000_option_override_internal):
> Override flag_cunroll_grow_size.
This part is fine of course. Thanks!
Segher
eds to use target information
(just like what ivopts does).
> So I'd like to see specific cases where you think cunroll should
> do "better" on powerpc only but not elsewhere.
It is probably not a good idea in general to unroll 14 times, yes :-)
Segher
ns
> without wanting them to be used for loop control, we could test for
> that case by checking whether while_ult_optab is implemented.
Heh, sneaky. But at least for now it will work fine, and it is local,
and not hard to change later.
Segher
wed to fail, they have to duplicate all the code that
the generic expander should have, into ever target that needs it. It
also makes writing a (new) backend easier.
Segher
_compare just tries GT for that anyway (not UNGE)
> so
> it is actually be handled (but should not?).
>
> So I bet the expansion of the patterns cannot fail at the moment. Thus I'd
> replace the FAIL with a gcc_unreachable () and see if we have test
> coverage for those
&
On Fri, May 29, 2020 at 05:57:13PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote:
> >> Now it looks like that those verification also simply checks optab
> >> availability only but then
On Fri, May 29, 2020 at 06:05:14PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Fri, May 29, 2020 at 02:43:12PM +0200, Richard Biener wrote:
> >> Segher - do you actually know this code to guess why the patterns are
> >> defensive?
> >
&g
On Fri, May 29, 2020 at 06:26:55PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > Most patterns *do* FAIL on some target. We cannot rewind time.
>
> Sure. But the point is that FAILing isn't “explicitly allowed” for vcond*.
> In fact it's the
ng at a stfs which doesn't
> + looking like the other things that we are looking for. */
s/looking/look/ I guess?
> + if (non_prefixed == NON_PREFIXED_X && is_stfs_insn (insn))
> +return address_is_prefixed (addr, mem_mode, NON_PREFIXED_DEFAULT);
> + else
> +return address_is_prefixed (addr, mem_mode, non_prefixed);
Rest looks fine :-) Okay for trunk with the nits fixed and the
suggestions looked at. Also okay for 10, if wanted there?
Thanks!
Segher
nd most insns before or after this insn will be VSX as well).
This changes the define_insns for the mrg and perm machine instructions
to prefer the VSX form. No behaviour change. Only one testcase needed
a little adjustment as well.
Tested on powerpc64-linux {-m32,-m64}. Applying to trunk.
Hi!
On Sat, May 30, 2020 at 08:15:55AM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> >> Sure. But the point is that FAILing isn't “explicitly allowed” for vcond*.
> >> In fact it's the opposite.
I disagree btw, and no one else has noticed f
not a problem on any existing core AFAIR, not for DP at least.
Things are different if more is done then just moving the data, there
are issues with using SP data in DP insns for example (and OTOH, on
older cores using DP data in SP insns isn't actually supported).
Maybe I am missing something... I'll look at the patch in detail ;-)
Segher
ntrinsics
> would have been happy with the 32-bit IV.
It's a shift left always. All bits beyond the 8 drop out.
Thanks for the great reviews Richard, much appreciated!
Segher
d expand to something better
already (not expand to a block move at all, certainly not for something
as tiny as this).
Segher
y not for something
> > as tiny as this).
>
> And please don't refer to homogeneous aggregates outside of ELFv2 ABI
> code because that will miss an optimization or generate incorrect code
> other PowerPC OSes and ABIs, such as AIX.
Yes, rs6000_discover_homogeneous_aggregate always returns false if some
other ABI is in use, which means for this particular code that the
problem isn't solved for those other ABIs at all.
Segher
ge with some cut&paste. To recap: vcond is
> equal to
>
> mask = vec_cmp of the comparison
> true_masked = true_op & mask;
> false_masked = false_op & ~mask;
> result = true_masked | false_masked;
>
> but I believe this would be dead code never triggered.
But that would be the generic code as well? Is that not useful to have
in any case?
Segher
to FAIL, and that is a very good
thing. If the vectoriser does not allow that, *it* is buggy.
> So if you're happy I'll document explicitly that vector named patterns may
> not FAIL.
That will not work in general at all, no. Please document it for only
those RTL patterns you need it for (and it is documented per pattern
currently, anyway).
Segher
> Subject: [PATCH] rs6000: replace FAIL with gcc_unreachable.
("Replace", and no dot at the end).
> * config/rs6000/vector.md: Replace FAIL with gcc_unreachable
> in all vcond* patterns.
Segher
On Wed, Jun 03, 2020 at 08:38:04PM +0200, Richard Biener wrote:
> On June 3, 2020 8:23:14 PM GMT+02:00, Segher Boessenkool
> wrote:
> >On Wed, Jun 03, 2020 at 07:23:47PM +0200, Richard Biener wrote:
> >> >> mask = vec_cmp of the comparison
> >&g
tor, also classical FP,
but maybe only the computational insns (not the moves))? Will need some
experimentation to find out something that works well (and that is the
point: it should be easy to *work with*, nothing else).
Sorry for blabbering :-)
Segher
r to just put them together in vector.me then, no matter
where they are used? But we should restructure this whole thing anyway,
just something to keep in the back of your head.
Okay for trunk with such tweaks. Thanks!
Segher
s[1], operands[2]));
> + DONE;
> +})
The two cases (BE and LE) are now exactly identical? Same for all
similar cases.
Okay for trunk with those nits taken care of. Thanks!
Segher
just .
>
> +(define_expand "vreplace_elt_"
> + [(set (match_operand:REPLACE_ELT 0 "register_operand")
> + (unspec:REPLACE_ELT [(match_operand:REPLACE_ELT 1 "register_operand")
Indent is a bit wrong here (the "unspec" should line up with the
"match_operand").
> + Endianess if needed. */
(two n's in endianness).
I think the rest is fine. Okay for trunk with these things fixed, or
resend it if you prefer?
Thanks!
Segher
t; It's also OK to backport this to the GCC 10 branch if powerpc
> folks want to restore GIMPLE cunroll behavior for their target.
Yes please! (But first make sure it works as expected, no fallout, etc.)
Thanks to both of you,
Segher
does not portably work (the function names can have
various prefixes added).
I cannot understand this code, and it does seem far from obviously
correct. But, okay for trunk if you handle all fallout (and I mean all,
not just "all you consider important").
Segher
debug this at least immediately gets to see
what is happening.
So, as on the other patch: okay for trunk, but you get to deal with all
the fallout. If you do not want to fix the obvious problems now,
you'll get to do it later.
Segher
so that everyone can easily comment on it.
If someone has published a modified GCC anywhere public, anyone can
take that code. That is how the GPL works.
But we still need it on gcc-patches to review it :-)
Segher
On Fri, Dec 11, 2020 at 10:16:44PM +0200, abebeos wrote:
> Στις Παρ, 11 Δεκ 2020 στις 10:02 μ.μ., ο/η Segher Boessenkool <
> seg...@kernel.crashing.org> έγραψε:
> > > My understanding of "non-FSF world-legals" is that something that is
> > > alrea
ter this change
it is plain wrong. "Default size is something else than the default
size if certain flags are set".
Segher
On Fri, Dec 11, 2020 at 05:07:28PM -0500, Michael Meissner wrote:
> On Thu, Dec 10, 2020 at 03:20:01PM -0600, Segher Boessenkool wrote:
> > > We use the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change this
> > > name. We
> > > - only do this if the defa
On Fri, Dec 11, 2020 at 11:20:01PM +0200, abebeos wrote:
> Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
> seg...@kernel.crashing.org> έγραψε:
> > > Ok, to speed things up, is it ok if I simply pick the patch that I've
> > > attached to the iss
nterested to being worked on to skilled developers who are
> willing to spend a lot of their free time and to give them a small financial
> reward in return. Normally, buying developer time for such extensive tasks
> is way more expensive, so the community should appreciate anyone willing
> to do such work for a comparably little amount of money.
+1. Well, +100 or such :-)
Segher
LT64 PROCESSOR_POWER8
Is this wise? Binaries won't run on many BE systems anymore with
this. (Linux still uses Power4 by default for BE, as well).
In either case: yes, whatever you guys decide here is fine. Also for
all backports you want. Thanks!
Segher
, we will just match the Linux setting.
Compile a very simple test and look at the .machine in the generated .s?
Does that do what you want?
Segher
hil already has write-after-approval, and he has committed many
patches to avr/ already.
Segher
machine test.s.*
> test.s.10: .machine power4
> test.s.9: .machine power4
>
> I'm not sure where GCC sets power8 for LE, but it's definitely somewhere else.
Yes... And I do not know where this power4 comes from. Mysteries :-)
> So IMO this patch is good to go.
Yes, thanks!
Segher
2201 - 2300 of 6091 matches
Mail list logo
