At Cauldron, the question came up whether the dynamic loader needs to
be taught about the new relocations for PC-relative addressing.
I think they would only matter if we supported PC-relative addressing
*and* text relocations. Is that really necessary?
These text relocations would not work reli
On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote:
> At Cauldron, the question came up whether the dynamic loader needs to
> be taught about the new relocations for PC-relative addressing.
>
> I think they would only matter if we supported PC-relative addressing
> *and* text relocatio
* Alan Modra:
> On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote:
>> At Cauldron, the question came up whether the dynamic loader needs to
>> be taught about the new relocations for PC-relative addressing.
>>
>> I think they would only matter if we supported PC-relative addressing
>
On Mon, Sep 23, 2019 at 10:37:29AM +0200, Florian Weimer wrote:
> * Alan Modra:
>
> > On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote:
> >> At Cauldron, the question came up whether the dynamic loader needs to
> >> be taught about the new relocations for PC-relative addressing.
> >>
* Alan Modra:
> On Mon, Sep 23, 2019 at 10:37:29AM +0200, Florian Weimer wrote:
>> * Alan Modra:
>>
>> > On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote:
>> >> At Cauldron, the question came up whether the dynamic loader needs to
>> >> be taught about the new relocations for PC-rel
On Mon, Sep 23, 2019 at 11:14:12AM +0200, Florian Weimer wrote:
> * Alan Modra:
>
> > On Mon, Sep 23, 2019 at 10:37:29AM +0200, Florian Weimer wrote:
> >> * Alan Modra:
> >>
> >> > On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote:
> >> > We've been discussing this inside IBM too. T
* Alan Modra:
> On Mon, Sep 23, 2019 at 11:14:12AM +0200, Florian Weimer wrote:
>> * Alan Modra:
>>
>> > On Mon, Sep 23, 2019 at 10:37:29AM +0200, Florian Weimer wrote:
>> >> * Alan Modra:
>> >>
>> >> > On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote:
>> >> > We've been discussing
Hi All,
I'm trying to figure out how to prevent LRA selecting alternatives that
result in values being copied from A to B for one instruction, and then
immediately back from B to A again, when there are apparently more
sensible alternatives available.
I have an insn with the following patter
For msp430-elf in the large memory model there are PSImode (20-bit) pointers.
POINTERS_EXTEND_UNSIGNED == 1 and "char" is unsigned by default.
We get poor code generated for the following code snippet:
const int table[2] = {1, 2};
int
foo (char i)
{
return table[i];
}
The RTL generated by exp
Fax Message for gcc@gcc.gnu.org
You have received a 1 page fax at 23.09.2019
* The reference number for this fax is efax-47344029941-3059-66022.
Please download and view the Microsoft Word attachment.
Please visit www.efax.eu/faq if you have any questions regarding this message
or you service.
On Mon, Sep 23, 2019 at 12:56 PM Andrew Stubbs wrote:
>
> Hi All,
>
> I'm trying to figure out how to prevent LRA selecting alternatives that
> result in values being copied from A to B for one instruction, and then
> immediately back from B to A again, when there are apparently more
> sensible al
On Mon, Sep 23, 2019 at 1:56 PM Jozef Lawrynowicz wrote:
>
> For msp430-elf in the large memory model there are PSImode (20-bit) pointers.
> POINTERS_EXTEND_UNSIGNED == 1 and "char" is unsigned by default.
>
> We get poor code generated for the following code snippet:
>
> const int table[2] = {1,
On 9/23/19 5:56 AM, Jozef Lawrynowicz wrote:
> For msp430-elf in the large memory model there are PSImode (20-bit) pointers.
> POINTERS_EXTEND_UNSIGNED == 1 and "char" is unsigned by default.
>
> We get poor code generated for the following code snippet:
>
> const int table[2] = {1, 2};
>
> int
On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote:
> [(set (match_operand:DI 0 "register_operand" "=Sg,v")
> (ashift:DI
> (match_operand:DI 1 "gcn_alu_operand" " Sg,v")
> (match_operand:SI 2 "gcn_alu_operand" " Sg,v")))
>(clobber (match_scratch:BI 3
On 23/09/2019 15:15, Segher Boessenkool wrote:
On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote:
[(set (match_operand:DI 0 "register_operand" "=Sg,v")
(ashift:DI
(match_operand:DI 1 "gcn_alu_operand" " Sg,v")
(match_operand:SI 2 "gcn_alu_operand" "
On Mon, Sep 23, 2019 at 03:39:08PM +0100, Andrew Stubbs wrote:
> On 23/09/2019 15:15, Segher Boessenkool wrote:
> >On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote:
> >> [(set (match_operand:DI 0 "register_operand" "=Sg,v")
> >> (ashift:DI
> >> (match_operand:DI 1
On 23/09/2019 16:21, Segher Boessenkool wrote:
Pass the register class or constraint or something like that to the hook,
then based on what the hook returns, either or not do the reject? So your
hook would special-case SCC_CONDITIONAL_REG, maybe a few more similar ones
(those are confusing names
On Mon, Sep 23, 2019 at 12:56:20PM +0100, Jozef Lawrynowicz wrote:
> (insn 2 4 3 2 (set (reg/v:HI 25 [ i ])
> (zero_extend:HI (reg:QI 12 R12 [ i ])))
> (nil))
> .
> (insn 7 6 8 2 (set (reg:PSI 28)
> (subreg:PSI (sign_extend:SI (reg/v:HI 25 [ i ])) 0))
> (nil))
>
> All
Greetings,
For the last several days the branch for multithreading in GSOC does not
build and
crashes like so:
make[4]: Leaving directory
`/home/xerofoify/GCC/powerpc64le-unknown-linux-gnu/libquadmath'
make[3]: Leaving directory
`/home/xerofoify/GCC/powerpc64le-unknown-linux-gnu/libquadmath
On 9/23/19 9:26 AM, Andrew Stubbs wrote:
> On 23/09/2019 16:21, Segher Boessenkool wrote:
>> Pass the register class or constraint or something like that to the hook,
>> then based on what the hook returns, either or not do the reject? So
>> your
>> hook would special-case SCC_CONDITIONAL_REG, may
On Mon, 23 Sep 2019 07:30:21 -0600
Jeff Law wrote:
> On 9/23/19 5:56 AM, Jozef Lawrynowicz wrote:
> > For msp430-elf in the large memory model there are PSImode (20-bit)
> > pointers.
> > POINTERS_EXTEND_UNSIGNED == 1 and "char" is unsigned by default.
> >
> > We get poor code generated for the
On Mon, 23 Sep 2019 10:56:55 -0500
Segher Boessenkool wrote:
> On Mon, Sep 23, 2019 at 12:56:20PM +0100, Jozef Lawrynowicz wrote:
> > (insn 2 4 3 2 (set (reg/v:HI 25 [ i ])
> > (zero_extend:HI (reg:QI 12 R12 [ i ])))
> > (nil))
> > .
> > (insn 7 6 8 2 (set (reg:PSI 28)
> >
Before I submit a Bugzilla report or try to cut down a test case, has any
one seen this problem when compiling the 526.blender_r benchmark from
SPEC 2017:
Compiling with '-Ofast -flto -march=native -fprofile-generate' on Aarch64:
during GIMPLE pass: vect
blender/source/blender/imbuf/intern/inde
Andrew Stubbs writes:
> On 23/09/2019 15:15, Segher Boessenkool wrote:
>> On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote:
>>>[(set (match_operand:DI 0 "register_operand" "=Sg,v")
>>> (ashift:DI
>>>(match_operand:DI 1 "gcn_alu_operand" " Sg,v")
>>>
On Mon, Sep 23, 2019 at 06:56:12PM +0100, Jozef Lawrynowicz wrote:
> > It could have just done that as
> >
> > (set (reg:PSI 28)
> > (zero_extend:PSI (reg:QI 12)))
> >
> > as far as I can see? Do you already have a machine pattern that matches
> > that?
>
> Yes that combination is what I w
On 9/23/19 8:19 PM, Steve Ellcey wrote:
Before I submit a Bugzilla report or try to cut down a test case, has any
one seen this problem when compiling the 526.blender_r benchmark from
SPEC 2017:
Compiling with '-Ofast -flto -march=native -fprofile-generate' on Aarch64:
during GIMPLE pass: vect
26 matches
Mail list logo
