Hi -
> Another "problem" with gengtype is that it doesn't know what types can
> end up in a PCH. The CFG data structures can *never* be in a PCH, but
> there still are PCH writer functions. This is true for many other data
> structures as well.
Yes, gengtype does not differentiate between GC and
Jan Hubicka writes:
> Note that I think Core has similar characteristics - at least for string
> operations
> it fares well with unalignes accesses.
Nehalem and later has very fast unaligned vector loads. There's still some
penalty when they cross cache lines however.
iirc the rule of thumb i
On Mon, Dec 10, 2012 at 11:02 AM, Richard Biener
wrote:
> On Mon, Dec 10, 2012 at 7:46 PM, Sharad Singhai wrote:
>> Hi,
>>
>> The new dump infrastructure was committed shortly before the trunk
>> entered stage 3.
>>
>> However, except the vectorization passes, other passes do not dump
>> anything
On Mon, Dec 10, 2012 at 7:46 PM, Sharad Singhai wrote:
> Hi,
>
> The new dump infrastructure was committed shortly before the trunk
> entered stage 3.
>
> However, except the vectorization passes, other passes do not dump
> anything in response to -fopt-info flags despite the documentation. I
> ca
On Mon, Dec 10, 2012 at 4:42 PM, Christophe Lyon
wrote:
> On 10 December 2012 10:02, Richard Biener wrote:
>> On Fri, Dec 7, 2012 at 6:30 PM, Richard Earnshaw wrote:
>>> On 07/12/12 15:13, Christophe Lyon wrote:
Hi,
As ARM supports unaligned vector accesses for almost no pena
Hi,
The new dump infrastructure was committed shortly before the trunk
entered stage 3.
However, except the vectorization passes, other passes do not dump
anything in response to -fopt-info flags despite the documentation. I
can prepare patches for a couple more passes so that they output more
me
On Mon, Dec 10, 2012 at 7:25 PM, Steven Bosscher wrote:
> Hello,
>
> While trying to bootstrap with GCAC checking enabled and some
> instrumentation to measure how often objects are being marked, I
> noticed that a lot of cache misses happen because already-marked
> objects are being tested again
Hello,
While trying to bootstrap with GCAC checking enabled and some
instrumentation to measure how often objects are being marked, I
noticed that a lot of cache misses happen because already-marked
objects are being tested again (e.g. via ggc_marked_p). This struck me
as rather odd, until I looke
>
> I agree that this is a sledgehammer. If aligned/unaligned loads/stores have
> the same cost then reflect that in the vectorized stmt cost hook. If that
> alone does not prevent peeling for alignment to happen then the fix is to
> not consider doing peeling for alignment if aligned/unaligned
On 10 December 2012 10:02, Richard Biener wrote:
> On Fri, Dec 7, 2012 at 6:30 PM, Richard Earnshaw wrote:
>> On 07/12/12 15:13, Christophe Lyon wrote:
>>>
>>> Hi,
>>>
>>> As ARM supports unaligned vector accesses for almost no penalty, I'd
>>> like to disable loop peeling on ARM targets.
>>>
>>>
Dear Sirs,
We have been developing many-core system in a program of“Extremely Low-power
Circuits and Systems (Green IT Project)”sponsored by New Energy and Industrial
Technology Development Organization (NEDO) which is one of National Project in
Japan.
We of Ritsumeikan University team are en
On Mon, Dec 10, 2012 at 10:02 AM, Richard Biener
wrote:
> On Fri, Dec 7, 2012 at 6:30 PM, Richard Earnshaw wrote:
>> On 07/12/12 15:13, Christophe Lyon wrote:
>>>
>>> Hi,
>>>
>>> As ARM supports unaligned vector accesses for almost no penalty, I'd
>>> like to disable loop peeling on ARM targets.
On Fri, Dec 7, 2012 at 6:30 PM, Richard Earnshaw wrote:
> On 07/12/12 15:13, Christophe Lyon wrote:
>>
>> Hi,
>>
>> As ARM supports unaligned vector accesses for almost no penalty, I'd
>> like to disable loop peeling on ARM targets.
>>
>> I have ran benchmarks on cortex-A9 (hard-float) and noticed
13 matches
Mail list logo
