On Thu, 2014-02-27 at 15:34 +0100, Richard Biener wrote:
>
> I've been hacking on a prototype that generates matching and
> simplification code from a meta-description.
For what it is worth, MELT has a similar feature. http://gcc-melt.org/
regards
--
Basile STARYNKEVITCH http://stary
> I think part of the problem is that some parts of GCC (like the one you
> noted) are far more conservative than others. E.g. take:
>
> void foo (int x, int *y)
> {
> y[0] = x + 1;
> asm volatile ("# asm");
> y[1] = x + 1;
> }
>
> The extra-paranoid check you pointed out means
> So, the main question is not about triggering condition, but about the
> behavior itself. Is it correct to flush and reload all constants ? They are
> constants after all, they are even not stored in .data section but inlined
> in the code, and thus cannot be modified.
I'd think that everyone m
On Fri, Feb 28, 2014 at 9:51 AM, Eric Botcazou wrote:
>> So, the main question is not about triggering condition, but about the
>> behavior itself. Is it correct to flush and reload all constants ? They are
>> constants after all, they are even not stored in .data section but inlined
>> in the co
Am 02/27/2014 06:03 PM, schrieb Richard Sandiford:
Yury Gribov writes:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
> Of course if the GIMPLE level doesn't care about the barrier then it doesn't
> make sense to be overly conservative at the RTL CSE level. Thus I think we
> can just remove this barrier completely.
Not clear to me, what happens e.g. for register variables?
--
Eric Botcazou
On Fri, Feb 28, 2014 at 10:23 AM, Eric Botcazou wrote:
>> Of course if the GIMPLE level doesn't care about the barrier then it doesn't
>> make sense to be overly conservative at the RTL CSE level. Thus I think we
>> can just remove this barrier completely.
>
> Not clear to me, what happens e.g. f
Hi!
Currently when libgomp hits an error (that is, an internal error,
possibly due to the user doing "stupid" things), after printing a message
libgomp/error.c:gomp_fatal terminates the executing process:
void
gomp_fatal (const char *fmt, ...)
{
va_list list;
va_start
Eric Botcazou writes:
>> One of the big grey areas is what should happen for floating-point ops
>> that depend on the current rounding mode. That isn't really modelled
>> properly yet though. Again, it affects calls as well as volatile asms.
>
> There is an explicit comment about this in the sch
Georg-Johann Lay writes:
> Notice that in code1, func might contain such asm-pairs to implement
> atomic operations, but moving costly_func across func does *not*
> affect the interrupt respond times in such a disastrous way.
>
> Thus you must be *very* careful w.r.t. optimizing against asm volati
> But here too the point is that we don't assume the same thing at the
> tree level or during register allocation. It seems a bit silly for
> the scheduler to assume that all hard registers are clobbered when the
> register allocator itself doesn't assume that. And most rtl passes
> assume that c
On Thu, 27 Feb 2014, Richard Biener wrote:
I've been hacking on a prototype that generates matching and
simplification code from a meta-description. The goal is
to provide a single source of transforms currently spread
over the compiler, mostly fold-const.c, gimple-fold.c and
tree-ssa-forwprop.
On Thu, Feb 27, 2014 at 9:34 AM, Richard Biener wrote:
> Comments or suggestions?
On the surface it looks like a nice idea. However, I would like to
understand the scope of this. Are you thinking of a pattern matcher
with peephole like actions? Or would you like to evolve a DSL capable
of wri
Hi,
I have noticed that a patch was placed in bugzilla to do this change, but it
does not appear to have been pushed. I was wondering if anyone could comment
why this is the case?
The bugzilla URL is the following:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57754
Many thanks,
Andrew
Andr
Hmm, this all reminds me about the approach Andrew Pinski and I came
up with two years ago. All in all I think it might be worth to
express folding-patterns in a more abstract way. So the md-like Lisp
syntax for this seems to be just stringent. We make use of such a
script-language already for
On 02/28/2014 03:37 AM, Thomas Schwinge wrote:
> The process cannot recover from this, trying to continue despite the
> error. (It is of course questionable what exactly to do in this case, as
> libgomp's internal state may now be corrupt.) So far, such errors may
> have been rare (aside from rea
On 02/28/14 16:05, Richard Henderson wrote:
I'd be ok with some kind of registration interface, like
old = omp_set_error_handler (new);
so that a library can set and restore the handler around its own omp usage.
I agree. An explicit API should be exposed to do this.
As for the interfac
Andrew Bennett writes:
> Hi,
>
> I have noticed that a patch was placed in bugzilla to do this change, but it
> does not appear to have been pushed. I was wondering if anyone could comment
> why this is the case?
>
> The bugzilla URL is the following:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi
On Fri, 2014-02-28 at 12:37 +0100, Thomas Schwinge wrote:
> Does it make sense to add the option for the user to install a handler
> for this?
The problem with calling a handler is that it's often hard to define
which state the program is in during the handler. If libgomp had to
terminate because
On Fri, 28 Feb 2014, Thomas Schwinge wrote:
> That aside, it is also an hurdle for ourselves if in libgomp's testsuite
> we want to test that the library does the right thing (abort) for
> non-sensible requests.
If you want to verify that a program exits with an error (so that exit
with an error
On Thu, Feb 27, 2014 at 12:53:12PM -0800, Paul E. McKenney wrote:
> On Thu, Feb 27, 2014 at 11:47:08AM -0800, Linus Torvalds wrote:
> > On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney
> > wrote:
> > >
> > > 3. The comparison was against another RCU-protected pointer,
> > > where th
21 matches
Mail list logo
