Hi Jeff,
On 13/01/16 19:28, Jeff Law wrote:
On 01/13/2016 04:33 AM, Kyrill Tkachov wrote:
I've been able to get it to do the right thing by changing the line
where it initially folds the source of the SET. That is line 4639 in
cse.c: /* Simplify and foldable subexpressions in SRC. Then get th
Hi.
On the i370 port of GCC 3.2.3 (which
can be run in 31-bit mode on z/OS),
we have the below code to do a
builtin_memcpy().
But as per description in i370.md, it
is restricted to moving LESS than
16 MiB.
If we have 16 MiB or more, I am happy
to just call the memcpy() function.
I have tried v
The following is mainly targeted at readers with a strong DWARF
background. Anybody else may read for interest/amusement or safely
ignore.
After analyzing some test case failures in GCC and GDB I realized that
there are various problems with the handling of DWARF pieces
(particularly from registe
On Wed, Jan 13, 2016 at 02:17:16PM +0100, Matthias Klose wrote:
> Here are some first results from a distro test rebuild using GCC 6.
> A snapshot of the current Ubuntu development series was taken on
> 20151218 for all architectures (amd64, arm64, armhf, i386/i686,
> powerpc, ppc64el, s390x), and
On 01/14/2016 03:15 AM, Kyrill Tkachov wrote:
There are cases where calls to fold_rtx with a non-NULL insn don't
end up modifying src, ending up in src to not be always equal to
src_folded (I added an assert to that effect and saw it trigger). It
seems that fold_rtx is not *guaranteed* to modify
On 01/14/2016 12:07 AM, Andrey Belevantsev wrote:
Hello Bernd,
On 13.01.2016 21:25, Bernd Schmidt wrote:
There are a few open PRs involving sel-sched, and I'd like to start a
discussion about removing it. Having two separate schedulers isn't a very
good idea in the first place IMO, and since ia
On 01/14/2016 06:26 PM, Jeff Law wrote:
I think the bigger question Bernd is asking here is whether or not it
makes sense to have multiple schedulers. In an ideal world we'd bake
them off select the best and deprecate/remove the others.
I didn't follow sel-sched development closely, so forgive
Guys,
I'm trying to make compiler to generate better code on superscalar
in-order machine but can't find the right way to do it.
Imagine the following code:
long f(long* p, long a, long b)
{
long a1 = a << 2;
long a2 = a1 + b;
return p[a1] + p[a2];
}
by default compiler generates somethin
On 01/14/2016 04:47 PM, Igor Shevlyakov wrote:
Guys,
I'm trying to make compiler to generate better code on superscalar
in-order machine but can't find the right way to do it.
Imagine the following code:
long f(long* p, long a, long b)
{
long a1 = a << 2;
long a2 = a1 + b;
return p[a1
Thanks Jeff,
I really hoped that I missed something and there was better answer.
But does it do any harm if combiner will try to check every piece of a
parallel like that and if every component is matchable and total cost
is not worse to emit them separately?
It will change nothing for single issu
On 01/14/2016 10:45 PM, Igor Shevlyakov wrote:
Thanks Jeff,
I really hoped that I missed something and there was better answer.
Nope, not really. Though thinking about it, you might want to look into
Bernd's work from 2012 in the haifa scheduler -- it's got some
intelligence for dependency br
11 matches
Mail list logo
