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
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
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
> 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
> 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
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
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
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 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
"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
-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
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
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
> +/* 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
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
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
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
17 matches
Mail list logo
