On 04/23/12 08:27, Ulrich Weigand wrote:
>> Ulrich, can you please provide some guidelines on how you think this
>> proposed functionality should be implemented?
>
> Well, you do not *have* to have a keyword for a special address space.
>
> One possible implementation might be:
>
> - You define
Uros Bizjak wrote:
> On Tue, Mar 27, 2012 at 7:20 PM, Richard Henderson wrote:
> > On 03/27/12 09:37, Uros Bizjak wrote:
> >>> > Now, in this particular case, there might be another option to
> >>> > avoid this hassle completely: =A0I understand that this UNSPEC is
> >>> > simply a magic marker to
On Tue, Mar 27, 2012 at 7:20 PM, Richard Henderson wrote:
> On 03/27/12 09:37, Uros Bizjak wrote:
>>> > Now, in this particular case, there might be another option to
>>> > avoid this hassle completely: I understand that this UNSPEC is
>>> > simply a magic marker to make the address use the fs: o
On 03/28/2012 02:40 AM, Uros Bizjak wrote:
> What about release branches? While this issue didn't trigger there
> yet, it can be triggered by some bad RA decision, and the fixup is
> missing.
I have no objection to your current patch being backported.
It looked fairly safe.
r~
On Tue, Mar 27, 2012 at 7:20 PM, Richard Henderson wrote:
> On 03/27/12 09:37, Uros Bizjak wrote:
>>> > Now, in this particular case, there might be another option to
>>> > avoid this hassle completely: I understand that this UNSPEC is
>>> > simply a magic marker to make the address use the fs: o
On Tue, Mar 27, 2012 at 8:34 PM, H.J. Lu wrote:
> %fs and %gs are special in 64bit mode. For a memory operand
> "%fs:address", its effective address is base address of %fs + address.
> The base address of %fs and %fs are hidden. "mov %fs, %eax"
> will only access the visible part of %fs, which i
On Tue, Mar 27, 2012 at 10:53 AM, Uros Bizjak wrote:
> On Tue, Mar 27, 2012 at 7:28 PM, H.J. Lu wrote:
>
>> GCC needs to move the value in the %fs segment
>> register into %r32 or %r64. This instruction
>>
>> "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
>>
>> does exactly what GCC wants.
>
> Sorr
On Tue, Mar 27, 2012 at 7:28 PM, H.J. Lu wrote:
> GCC needs to move the value in the %fs segment
> register into %r32 or %r64. This instruction
>
> "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}"
>
> does exactly what GCC wants.
Sorry, I really don't understand what you are trying to say.
You are
On Tue, Mar 27, 2012 at 9:57 AM, Uros Bizjak wrote:
> On Tue, Mar 27, 2012 at 6:57 PM, H.J. Lu wrote:
>
Well, generally speaking, reload makes a lot of assumptions on how
addresses can look like; it needs to, since if a target rejects an
address as invalid as-is, reload must fix it
On 03/27/12 09:37, Uros Bizjak wrote:
>> > Now, in this particular case, there might be another option to
>> > avoid this hassle completely: I understand that this UNSPEC is
>> > simply a magic marker to make the address use the fs: or gs:
>> > segment override, right? Now that GCC supports addr
On Tue, Mar 27, 2012 at 6:57 PM, H.J. Lu wrote:
>>> Well, generally speaking, reload makes a lot of assumptions on how
>>> addresses can look like; it needs to, since if a target rejects an
>>> address as invalid as-is, reload must fix it up -- and it can do
>>> so only by making assumptions ...
On Tue, Mar 27, 2012 at 9:37 AM, Uros Bizjak wrote:
> On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand wrote:
>
>>> Since fixing reload issues is some kind of black magic, I'd like to
>>> ask Ulrich and Richard for their opinion on this approach.
>>
>> Well, generally speaking, reload makes a lot
On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand wrote:
>> Since fixing reload issues is some kind of black magic, I'd like to
>> ask Ulrich and Richard for their opinion on this approach.
>
> Well, generally speaking, reload makes a lot of assumptions on how
> addresses can look like; it needs to
Uros Bizjak wrote:
> In a corner case of a reload, reload pass can generate partially
> reloaded address, where not all registers get allocated to a hard reg.
> When this address is checked with ix86_legitimate_address, it is
> rejected, since in strict mode, pseudos are not valid address
> regist
On Mon, Mar 26, 2012 at 9:03 PM, H.J. Lu wrote:
>>> Attached patch fixes this situation by (partially) reloading only
>>> remaining pseudo(s), leaving UNSPEC in the address RTX.
>>>
>>> 2012-03-26 Uros Bizjak
>>>
>>> PR target/52698
>>> * config/i386/i386-protos.h (ix86_legitimiz
On Mon, Mar 26, 2012 at 10:41 AM, H.J. Lu wrote:
> On Mon, Mar 26, 2012 at 10:25 AM, Uros Bizjak wrote:
>> Hello!
>>
>> In a corner case of a reload, reload pass can generate partially
>> reloaded address, where not all registers get allocated to a hard reg.
>> When this address is checked with i
On Mon, Mar 26, 2012 at 10:25 AM, Uros Bizjak wrote:
> Hello!
>
> In a corner case of a reload, reload pass can generate partially
> reloaded address, where not all registers get allocated to a hard reg.
> When this address is checked with ix86_legitimate_address, it is
> rejected, since in strict
Hello!
In a corner case of a reload, reload pass can generate partially
reloaded address, where not all registers get allocated to a hard reg.
When this address is checked with ix86_legitimate_address, it is
rejected, since in strict mode, pseudos are not valid address
registers. So, reload tries
18 matches
Mail list logo
