On 01/03/2012 09:48 AM, Jim Meyering wrote:
Paolo Bonzini wrote:
* bootstrap.conf: Add isatty module.
* gnulib: Update to latest.
* lib/colorize.h: Remove argument from should_colorize.
* lib/ms/colorize.h: Likewise.
* lib/colorize-impl.c: Factor isatty call out of here...
* lib/ms/colorize-imp
Paolo Bonzini wrote:
> On 01/03/2012 09:48 AM, Jim Meyering wrote:
>> Paolo Bonzini wrote:
>>
>>> * bootstrap.conf: Add isatty module.
>>> * gnulib: Update to latest.
>>> * lib/colorize.h: Remove argument from should_colorize.
>>> * lib/ms/colorize.h: Likewise.
>>> * lib/colorize-impl.c: Factor is
Hi Dmitry,
Sorry about the late reply - been on vacation and catching up today on
email.
Here's why I'm asking. In the following example, dependence cost of 32
for cortex_a8_call causes insns 464 and 575 to be separated by 308 (in
spite having same priority), because 575 is not ready at tick
On Mon, Jan 2, 2012 at 10:54 PM, Richard Guenther
wrote:
> Yes. It won't handle
>
> if (x > 1)
> ...
> tem = x > 1;
>
> or
>
> if (x > 1)
> ...
> if (x > 1)
>
> though maybe we could teach PRE to do the insertion by properly
> putting x > 1 into EXP_GEN in compute_avail (but not into AVA
For discussions around programming languages, within GNU, but not specific
to a particular GNU package, there is now a mailing list
.
The subscription page is here:
https://lists.gnu.org/mailman/listinfo/language-experts
You are invited to join if you have extensive experience in this area.
Topi
I have multi-threaded C++ application that relies on fine-grain parallelism and
makes extensive use of interlocked instructions and memory barriers for
inter-thread synchronization and communication.
I currently use LFENCE/SFENCE/MFENCE instructions for memory barriers (on
processors that have
Sergey Oboguev writes:
> The question is whether there is any GCC/runtime policy on non-temporal
> SSE/3DNow instructions?
As far as I know gcc will never generate any non-temporal instructions,
except if the programmer uses the special intrinsic functions which
generate them. If the programme
Well, all these
storent
emit_storent_insn
may_use_storent_in_loop
storent_optab
nontemporal
assign_set_nontemporal_move
mark_nontemporal_store
mark_nontemporal_stores
nontemporal_store_p
schedule_prefetches
should_issue_prefetch
issue_prefetch_ref
Sergey Oboguev writes:
> Well, all these
>
> storent
> emit_storent_insn
> may_use_storent_in_loop
> storent_optab
> nontemporal
> assign_set_nontemporal_move
> mark_nontemporal_store
> mark_nontemporal_stores
> nontemporal_store_p
> schedule_prefetches
>
Well, it would help if someone who knows what this code does (and does not),
ideally its authors, could clarify definitively.
Also, what happens if application performs inter-thread communication inside
the
loop?
- Sergey
- Original Message
From: Ian Lance Taylor
To: Sergey Obogue
10 matches
Mail list logo