> On Jul 6, 2018, at 6:18 AM, Bernd Edlinger wrote:
>
> You can get much better code if you make xrci a bit field.
> so the entire bit filed region can be accessed word-wise:
>
>
> #include
>
> struct Xrb
> {
>uint16_t xrlen; /* Length of I/O buffer in bytes */
>uint16_
You can get much better code if you make xrci a bit field.
so the entire bit filed region can be accessed word-wise:
#include
struct Xrb
{
uint16_t xrlen; /* Length of I/O buffer in bytes */
uint16_t xrbc; /* Byte count for transfer */
void * xrloc;
> Xstormy does 3 mov.b also. For that matter, so does the x86 target (both
> -m32 and -m64). Hm.
Indeed, even at -Os, so this may be a generic issue.
--
Eric Botcazou
> On Jul 5, 2018, at 9:01 PM, Paul Koning wrote:
>
>
>
>> On Jul 5, 2018, at 6:47 PM, Eric Botcazou wrote:
>>
>>> So back to the previous one: anything I can do about a 24 bit field getting
>>> split into three movqi rather than a movqi plus a movhi? That happens
>>> during RTL expand, I
> On Jul 5, 2018, at 6:47 PM, Eric Botcazou wrote:
>
>> So back to the previous one: anything I can do about a 24 bit field getting
>> split into three movqi rather than a movqi plus a movhi? That happens
>> during RTL expand, I believe.
>
> Yes, this one doesn't look as hopeless as the stor
> So back to the previous one: anything I can do about a 24 bit field getting
> split into three movqi rather than a movqi plus a movhi? That happens
> during RTL expand, I believe.
Yes, this one doesn't look as hopeless as the store merging issue. A way of
tackling it would be to do a side-by-
> On Jul 5, 2018, at 4:44 PM, Eric Botcazou wrote:
>
> ...
> The GIMPLE pass responsible for the optimization simply punts for the "funny-
> endian ordering" of the PDP11. More generally, you shouldn't expect anything
> sparkling for such a peculiar architecture as the PDP11.
Ok. Yet anoth
> I just constructed another test case that shows the same issue more
> blatantly:
>
> struct s
> {
> char a;
> char b;
> char c;
> char d;
> int e;
> int f;
> char h;
> char i;
> };
No, it's not the same issue.
> struct s ts;
>
> void setts(void)
> {
> ts.a=
> On Jul 5, 2018, at 12:01 PM, Segher Boessenkool
> wrote:
>
> On Thu, Jul 05, 2018 at 08:45:30AM -0400, Paul Koning wrote:
>> I have a struct that looks like this:
>>
>> struct Xrb
>> {
>>uint16_t xrlen; /* Length of I/O buffer in bytes */
>>uint16_t xrbc;/* By
On Thu, Jul 05, 2018 at 08:45:30AM -0400, Paul Koning wrote:
> I have a struct that looks like this:
>
> struct Xrb
> {
> uint16_t xrlen; /* Length of I/O buffer in bytes */
> uint16_t xrbc;/* Byte count for transfer */
> void * xrloc; /* Pointer to I/
I have a struct that looks like this:
struct Xrb
{
uint16_t xrlen; /* Length of I/O buffer in bytes */
uint16_t xrbc; /* Byte count for transfer */
void * xrloc; /* Pointer to I/O buffer */
uint8_t xrci; /* Channel number times 2
Stefan Strasser wrote:
movl %ebx, -200(%ebp)
movl %ebx, -196(%ebp)
movl %eax, 4(%esp)
movl -200(%ebp), %edx
movl -196(%ebp), %ecx
It is hard to say without a testcase, but my first guess would be reload
inheritance and/or the post-reload cse pass.
Reload may need to load/store something from
is there a reason for code output like the following or is this a bug?
if it is I can try to provide a simple example.
movl %ebx, -200(%ebp)
movl %ebx, -196(%ebp)
movl %eax, 4(%esp)
movl -200(%ebp), %edx
movl -196(%ebp), %ecx
gcc 3.4.3, -O3 -march=pentium4 -mtune=pentium4 -mfpmatch=sse -msse2
13 matches
Mail list logo
