On Wed, Nov 16, 2011 at 10:46 PM, Richard Henderson wrote:
>> +/* Checks for an atomic sequence of instructions beginning with a
>> LWARX/LDARX
>> + instruction and ending with a STWCX/STDCX instruction. If such a
>> sequence
>> + is found, attempt to step through it. A breakpoint is place
On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou wrote:
>> Huh, IVOPTs should never cause a different size memory read. I wonder
>> if the original issue would still reproduce with the fix reverted.
>
> The original issue was unaligned arrays in packed structures. I don't see
> what
> could have
Quoting Feng LI :
So I suppose with (clobber (reg:CC FLAGS_REG)), the compiler
will be capable to know this register will be modified in this
instruction and
apply proper behavior when necessary?
Depends. It will stop the compiler moving a FLAGS_REG setter and/or user
such that FLAGS_REG
> +/* Checks for an atomic sequence of instructions beginning with a LWARX/LDARX
> + instruction and ending with a STWCX/STDCX instruction. If such a sequence
> + is found, attempt to step through it. A breakpoint is placed at the end
> of
> + the sequence. */
> +
s/LWARX/LDL_L/g
s/LDAR
On Sun, Nov 13, 2011 at 10:41 PM, Richard Henderson wrote:
> On 11/12/2011 07:38 AM, Uros Bizjak wrote:
>> On Fri, Nov 11, 2011 at 8:58 PM, Dominique Dhumieres
>> wrote:
>>
>>> For the record, Jakub's comment on IRC:
>>>
with older gdb you simply had to find the stwcx
or whatever SC in
Hi,
On Wed, 16 Nov 2011, Jeff Law wrote:
> Right. In theory, path isolation would make this optimizable. Make a
> copy of the block containing a[x] = 2 and make it the target when x !=
> 100. At the source level it'd look something like this:
>
> int x;
> extern void f(void);
>
> void g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/16/11 04:00, Richard Guenther wrote:
> On Mon, Nov 14, 2011 at 9:01 AM, Jiangning Liu
> wrote:
>> Hi,
>>
>> For this test case,
>>
>> int x; extern void f(void);
>>
>> void g(int *a) { a[x] = 1; if (x == 100) f(); a[x] = 2; }
>>
>> For trunk
"Rick C. Hodgin" writes:
> What's the best way to learn about developing GCC? Not developing in
> GCC, but understanding and extending the compiler's design itself?
Start by reading http://gcc.gnu.org/onlinedocs/gccint/ and
http://gcc.gnu.org/wiki/ .
Ian
On Wed, Nov 16, 2011 at 08:39:23AM -0500, Rick C. Hodgin wrote:
> What's the best way to learn about developing GCC? Not developing in
> GCC, but understanding and extending the compiler's design itself?
[It really depends of what you want to do inside GCC, but]
Learn more about the pass mac
Hi,
On Wed, 16 Nov 2011, Eric Botcazou wrote:
> > f() may change the value of x, so you cannot optimize away the load on that
> > execution path.
>
> This looks more like an aliasing issue with a, doesn't it?
Correct. There's no call to f() between a[x] and x==100, but the store to
a[x] might
On Wed, Nov 16, 2011 at 12:18 PM, Joern Rennecke wrote:
> Quoting Ian Lance Taylor :
>
>> Offhand I don't know of any way to get the compiler to save CC for you
>> around your instruction. That's a stiff requirement.
>
> It's easy to do under explicit control of the pattern, using (a)
> match_scr
What's the best way to learn about developing GCC? Not developing in
GCC, but understanding and extending the compiler's design itself?
Thanks,
Rick C. Hodgin
> f() may change the value of x, so you cannot optimize away the load on that
> execution path.
This looks more like an aliasing issue with a, doesn't it?
--
Eric Botcazou
> Huh, IVOPTs should never cause a different size memory read. I wonder
> if the original issue would still reproduce with the fix reverted.
The original issue was unaligned arrays in packed structures. I don't see what
could have changed since then.
--
Eric Botcazou
Quoting Ian Lance Taylor :
Offhand I don't know of any way to get the compiler to save CC for you
around your instruction. That's a stiff requirement.
It's easy to do under explicit control of the pattern, using (a) match_scratch
clobber(s) of (a) register(s) of the required class(es) - or if
On Mon, Nov 14, 2011 at 9:01 AM, Jiangning Liu wrote:
> Hi,
>
> For this test case,
>
> int x;
> extern void f(void);
>
> void g(int *a)
> {
> a[x] = 1;
> if (x == 100)
> f();
> a[x] = 2;
> }
>
> For trunk, the x86 assembly code is like below,
>
> movl
On Mon, Nov 14, 2011 at 4:58 AM, Yuehai Du wrote:
> Hi
>
> i found IVOPTS didn't work well on some case if the loop contain
> some unaligned access. it didn't take this kind of memory access into
> account because this check in function:find_interesting_uses_address
>
> /* Moreover, on stric
17 matches
Mail list logo
