Hi,
I am trying to demonstrate my port capabilities.
I am writing an application which needs to use instructions like max
a,b,c,d,e,f where a,b,c are inputs and d,e,f are outputs.
Is that possible to write an intrinsic function for that?
I think not because that means that I need to pass d,e,f by
On 10/25/2010 10:39 PM, Frank Ch. Eigler wrote:
> It would seem to moot the present discussion about competing elf
> consumer libraries. "none of the above" is a possible answer.
True. It seems that LTO and Go need a very simple interface; presumably
we can abstract that in the compiler and the
Hi -
> > By the way, is there some necessity in accomplishing this by means of
> > a linked library, as opposed to via a spawned objcopy process?
> Probably none in theory, but it certainly seems messy and likely to
> be slow in practice.
Yes, maybe.
> Is there a reason that this would be desir
On 10/25/2010 10:34 PM, Frank Ch. Eigler wrote:
> By the way, is there some necessity in accomplishing this by means of
> a linked library, as opposed to via a spawned objcopy process?
Probably none in theory, but it certainly seems messy and likely to be
slow in practice. Is there a reason that
Dave Korn writes:
> [...] From Ian's description, gccgo has the exact same requirements
> as LTO: be able to parse an object file, get a list of sections, and
> get raw binary access to the data contained within a named section.
> This is a problem which we already have solved. (And indeed LTO'
On 10/25/2010 10:07 PM, Dave Korn wrote:
> - integrate gccgo, with elfcpp
> - then common out the file-reading stuff from gcc/lto/ up to gcc/ so that all
> the FEs can share it
> - then convert it to use elfcpp (with a bit of file I/O added) and stop using
> libelf altogether
> - then switch gccgo
On 25/10/2010 23:49, Mark Mitchell wrote:
> On 10/25/2010 7:01 PM, Dave Korn wrote:
>
>> What would be even nicer would be if we could share the same code-reader
>> interface between lto and go (and the lto-plugin), thereby getting object
>> format independence equally everywhere for no extra co
On 26/10/2010 01:53, Paul Koning wrote:
> On Oct 25, 2010, at 3:44 PM, Richard Guenther wrote:
>
>> On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning
>> wrote:
>>> Question on movmemm:
>>>
>>> Given
>>>
>>> extern int *i, *j; void foo (void) { memcpy (i, j, 10); }
>>>
>>> I would expect to see arg
On Oct 25, 2010, at 3:44 PM, Richard Guenther wrote:
> On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning wrote:
>> Question on movmemm:
>>
>> Given
>>
>> extern int *i, *j;
>> void foo (void) { memcpy (i, j, 10); }
>>
>> I would expect to see argument 4 (the shared alignment) to be sizeof(int)
>
On 10/25/2010 7:01 PM, Dave Korn wrote:
> What would be even nicer would be if we could share the same code-reader
> interface between lto and go (and the lto-plugin), thereby getting object
> format independence equally everywhere for no extra cost.
>
> That could be orthogonal to plugging e
On 25/10/2010 19:43, Andi Kleen wrote:
> Andrew Pinski writes:
>
>> On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor wrote:
>>> At least, that is how I see it.
>> Why not require libelf just like for LTO? That seems like a time to
>> reduce what we depend on. For an example if we compile wit
> redriver jiang writes:
>
> > I meet a requirement to make all function calls to be indirect
> > function calling ( for I386 GCC compiler). I am not familiar with
> > frontend, so my first idea is
> >
> > to hack it from backend, change the asm output for "call" and
> > "call_value" insn pattern
Paul Koning writes:
> Working on the pdp11 target, I ran into something odd.
>
> It defines REGNO_OK_FOR_BASE_P in a way that seems to match what gccint says
> one should do in the "strict" case -- but does so all the time.
> Specifically, it says:
>
> #define REGNO_OK_FOR_BASE_P(REGNO) \
>
On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning wrote:
> Question on movmemm:
>
> Given
>
> extern int *i, *j;
> void foo (void) { memcpy (i, j, 10); }
>
> I would expect to see argument 4 (the shared alignment) to be sizeof(int)
> since both argument are pointers to int. What I get instead is 1.
redriver jiang writes:
> I meet a requirement to make all function calls to be indirect
> function calling ( for I386 GCC compiler). I am not familiar with
> frontend, so my first idea is
>
> to hack it from backend, change the asm output for "call" and
> "call_value" insn patterns, generate a re
roy rosen writes:
> In my port I get to such a situation:
>
> (insn 60 59 61 4 a.c:65 (set (subreg:SI (reg:HI 129 [ __prephitmp_4 ]) 0)
> (zero_extract:SI (subreg:SI (reg/v:DI 138 [ v4hi1 ]) 4)
> (const_int 16 [0x10])
> (const_int 16 [0x10]))) 53 {extzv} (nil))
>
>
On Thu, 7 Oct 2010, James Miller wrote:
> Our mirror address has been changed from
>
> http://gcc.parentinginformed.com/
>
> to
>
> http://gcc.parentingamerica.com/
>
> Please update your list to use the new URL.
>
> Also please use new e-mail to contact me when necessary:
> jmil...@parentinga
Andrew Pinski writes:
> On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor wrote:
>> At least, that is how I see it.
>
> Why not require libelf just like for LTO? That seems like a time to
> reduce what we depend on. For an example if we compile with lto and
> go, GCC will use two different el
On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor wrote:
> At least, that is how I see it.
Why not require libelf just like for LTO? That seems like a time to
reduce what we depend on. For an example if we compile with lto and
go, GCC will use two different elf libraries. This seems dumb real
Mark Mitchell writes:
> On 10/24/2010 10:52 PM, Ian Lance Taylor wrote:
>
>> It's hard for me to believe that BFD is the correct answer. It's poorly
>> designed for the kinds of things the compiler needs to do. Any program
>> which links against BFD effectively links in the GNU linker.
>
> It s
Frederic Riss writes:
> On 22 October 2010 20:17, Ian Lance Taylor wrote:
>> Frederic Riss writes:
>>> OK... what's the best way forward on this? Do we just leave it as it
>>> is and wait until an official port needs complains about it? Should it
>>> be filled in bugzilla?
>>
>> Did you just ha
Question on movmemm:
Given
extern int *i, *j;
void foo (void) { memcpy (i, j, 10); }
I would expect to see argument 4 (the shared alignment) to be sizeof(int) since
both argument are pointers to int. What I get instead is 1. Why is that?
If I have
extern int i[10], j[10];
then I do get la
On 10/24/2010 10:52 PM, Ian Lance Taylor wrote:
> It's hard for me to believe that BFD is the correct answer. It's poorly
> designed for the kinds of things the compiler needs to do. Any program
> which links against BFD effectively links in the GNU linker.
It sounded from your mail like all th
redriver jiang writes:
> Hi,
>
> I meet a requirement to make all function calls to be indirect
> function calling ( for I386 GCC compiler). I am not familiar with
> frontend, so my first idea is
For x86-64 using the "large" code model (-mcmodel=large) will result in
all function calls being ind
Working on the pdp11 target, I ran into something odd.
It defines REGNO_OK_FOR_BASE_P in a way that seems to match what gccint says
one should do in the "strict" case -- but does so all the time. Specifically,
it says:
#define REGNO_OK_FOR_BASE_P(REGNO) \
((REGNO) < 8 || (unsigned) reg_renum
On 10/25/2010 10:46 AM, Frederic Riss wrote:
Hi,
The constant propagation pass propagates constants into the
instructions that accept immediates. I'm trying to find if there's
some CSE pass in GCC that would be able to undo this effect when the
constant is used more than once in the function. I
On 10/25/2010 11:35 AM, Georg Lay wrote:
(insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
(and:SI (reg:SI 4 d4 [ x ])
(const_int -98305 [0xfffe7fff]))) 143
{*and3_zeroes.insert.{SI}.ic}
(nil))
(insn 23 22 21 2 peep2.c:5 (set (reg:SI 15 d15)
(xor:SI (reg:SI
Hi,
I meet a requirement to make all function calls to be indirect
function calling ( for I386 GCC compiler). I am not familiar with
frontend, so my first idea is
to hack it from backend, change the asm output for "call" and
"call_value" insn patterns, generate a related varible in data
section,
Paolo Bonzini schrieb:
> On 10/22/2010 01:16 PM, Georg Lay wrote:
>> Then the first insn gets split after reload and before peephole2:
>>
>> (insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
>> (and:SI (reg:SI 4 d4 [ x ])
>> (const_int -98305 [0xfffe7fff]))) 143
>> {*and3_zeroes.
Hi,
The constant propagation pass propagates constants into the
instructions that accept immediates. I'm trying to find if there's
some CSE pass in GCC that would be able to undo this effect when the
constant is used more than once in the function. I looked at the CSE
code (4.5 branch) and I don't
In my port I get to such a situation:
(insn 60 59 61 4 a.c:65 (set (subreg:SI (reg:HI 129 [ __prephitmp_4 ]) 0)
(zero_extract:SI (subreg:SI (reg/v:DI 138 [ v4hi1 ]) 4)
(const_int 16 [0x10])
(const_int 16 [0x10]))) 53 {extzv} (nil))
(insn 61 60 62 4 a.c:65 (set (reg
On 22 October 2010 20:17, Ian Lance Taylor wrote:
> Frederic Riss writes:
>> OK... what's the best way forward on this? Do we just leave it as it
>> is and wait until an official port needs complains about it? Should it
>> be filled in bugzilla?
>
> Did you just happen to come across this, or is
32 matches
Mail list logo
