Hello Joe,
The other hurdle would be the ABI. It's very particular since it has
to accommodate calling into and from EBC, x86, x86_64, ia64, and any
other architecture available. It's structured mainly on Microsoft's
stdcall ABI.
I have read the part about EBC of EFI specification.But I foun
surfing the web, searching some tool for statically analize the stack
usage I found a pdf from 5 years ago, from the 2005 GCC Developers’
Summit:
http://www.gccsummit.org/2005/2005-GCC-Summit-Proceedings.pdf
In that document is described a GCC command line options: -fstack-usage
(par 2.2.1, pag 96
Hello Andrew,
Who would maintain this EFI back-end?
The EFI specification was originally developed by Intel, and is now
managed by the Unified EFI Forum[http://www.uefi.org/home/].
So, you don't know who would maintain the EFI back-end that you're
proposing for gcc?
I feel sorry that I mis
> I use avr-gcc and arm-elf-gcc, both version 4.4.3.
> I tryed to invoke gcc with -fstack-usage:
>
> cc1: error: unrecognized command line option "-fstack-usage"
>
> why?
Presumably because the option isn't implemented in this compiler.
> where is that option?
An old version is at http://gcc.gnu
Jae Hyuk Kwak writes:
> [...]
> Is that true that current implementation of gcc on i386 optimizes
> switch statement with decision tree?
> I was expecting somebody who can confirm this.
You can see for yourself by writing a variety of switch{} statements
and observing the assembly code (-fverbos
Il giorno ven, 19/03/2010 alle 13.20 +0100, Eric Botcazou ha scritto:
> > I use avr-gcc and arm-elf-gcc, both version 4.4.3.
> > I tryed to invoke gcc with -fstack-usage:
> >
> > cc1: error: unrecognized command line option "-fstack-usage"
> >
> > why?
>
> Presumably because the option isn't imple
Hello Tristan,
I think the main issue is that EFI C dialect is not ANSI-C
compliant: the size of pointer is determined
at the run-time and therefore the layout of the structure is not
static. Gcc doesn't support this model.
As I read some related information, LLVM IR doesn't care the size
> And why this option has been removed?
It hasn't, it never got merged in the FSF tree.
> no hope to have that option again in upcoming versions of gcc?
Some hope to have it merged at some point, but no promises as usual.
--
Eric Botcazou
On 16/03/2010 09:15, Sean D'Epagnier wrote:
> I went through the c++ parser and added support for fixed point there.
> Everything seems to be working, and I am able to use fixed-point
> numbers in c++.
>
> The c++ parser is kind of complex and it is possible I missed
> something. I would love t
On Mar 19, 2010, at 1:33 PM, b95705...@ntu.edu.tw wrote:
> Hello Tristan,
>
>> I think the main issue is that EFI C dialect is not ANSI-C compliant: the
>> size of pointer is determined
>> at the run-time and therefore the layout of the structure is not static.
>> Gcc doesn't support this mod
On Mar 19, 2010, at 12:48 PM, b95705...@ntu.edu.tw wrote:
> I use Macbook with refit ,and its EFI shell version is 1.10.I have read
> some related information but I don't find how to launch EBC virture machine.
> I am truely want to know how could I launch it with fully appreciation.
> And I am wo
On Fri, Mar 19, 2010 at 1:06 AM, fanqifei wrote:
> On Thu, Mar 18, 2010 at 2:30 AM, Jim Wilson wrote:
>> On Wed, 2010-03-17 at 11:27 +0800, fanqifei wrote:
>>> You are correct. The reload pass emitted the clr.w insn.
>>> However, I can see loop opt passes after reload:
>>> problem1.c.174r.loop2_i
David Miller wrote:
> You said you would fix this several nights ago, but I still
> haven't seen any changes to fixincludes since then.
>
> When will you get around to fixing these regressions you
> introduced?
>
> Thank you.
Done. Terribly sorry for the delay. I became unemployed and
got a tw
Hi,
What does this message really mean?
i.e. What should I do about it?
ld.so should be loading shared objects in /usr/local/lib,
and that is where libmpc.so lives, so what gives?
Thanks - Bruce
> $ cat /etc/SuSE-release
> openSUSE 11.1 (x86_64)
> VERSION = 11.1
> $ ../configure --prefix=/old-ho
Hi folks!
I've moved on from register allocation (see Understanding IRA thread)
and onto scheduling.
In particular, I am investigating the effectiveness of the sched1
pass on our architecture and the associated interblock-scheduling
optimisation.
Let's start with sched1 ...
For our architectur
On Fri, Mar 19, 2010 at 5:02 PM, Bruce Korb wrote:
> Hi,
>
> What does this message really mean?
> i.e. What should I do about it?
run ldconfig or use binaries from
http://download.opensuse.org/repositories/devel:/gcc/openSUSE_11.1
Richard.
> ld.so should be loading shared objects in /usr/local
On 19/03/2010 16:02, Bruce Korb wrote:
> Hi,
>
> What does this message really mean?
What it really means is that configure couldn't get the compiler to work, it
doesn't know why, but anyway that there was no object file created after it
tried to invoke the compiler from which it could attempt
Hi Richard,
On Fri, Mar 19, 2010 at 9:12 AM, Richard Guenther
wrote:
> On Fri, Mar 19, 2010 at 5:02 PM, Bruce Korb wrote:
>> Hi,
>>
>> What does this message really mean?
>> i.e. What should I do about it?
>
> run ldconfig or use binaries from
> http://download.opensuse.org/repositories/devel:/g
On Fri, 19 Mar 2010, Ian Bolton wrote:
> Let's start with sched1 ...
>
> For our architecture at least, it seems like Richard Earnshaw is
> right that sched1 is generally bad when you are using -Os, because
> it can increase register pressure and cause extra spill/fill code when
> you move indep
On 03/19/2010 12:09 PM, Ian Bolton wrote:
Hi folks!
I've moved on from register allocation (see Understanding IRA thread)
and onto scheduling.
In particular, I am investigating the effectiveness of the sched1
pass on our architecture and the associated interblock-scheduling
optimisation.
Let'
> > Let's start with sched1 ...
> >
> > For our architecture at least, it seems like Richard Earnshaw is
> > right that sched1 is generally bad when you are using -Os, because
> > it can increase register pressure and cause extra spill/fill code
> when
> > you move independent instructions in betwe
On Fri, Mar 19, 2010 at 5:09 PM, Ian Bolton wrote:
> Anyway, the reason I mention interblock-scheduling is that I see it
> doing seemingly intelligent moves, but then the later BB-reorder pass
> is juggling blocks around such that we end up with extra code inside
> hot loops! I assume this is bec
> > I mention all this because I was wondering which other architectures
> > have turned off sched1 for -Os? More importantly, I was wondering
> > if anyone else had considered creating some kind of clever hybrid
> > that only uses sched1 when it will increase performance without
> > increasing re
On 03/19/2010 12:47 PM, Ian Bolton wrote:
I mention all this because I was wondering which other architectures
have turned off sched1 for -Os? More importantly, I was wondering
if anyone else had considered creating some kind of clever hybrid
that only uses sched1 when it will increase performan
On Mar 19, 2010, at 5:33 AM, b95705...@ntu.edu.tw wrote:
> Hello Tristan,
>
>> I think the main issue is that EFI C dialect is not ANSI-C compliant: the
>> size of pointer is determined
>> at the run-time and therefore the layout of the structure is not static.
>> Gcc doesn't support this mod
Let me correct my mistake.
> If I understood correctly, your point is that O(log N) is fast enough
> because the size of switch is small in practice.
> But I am still not convinced that using hash table would not increase the
> speed.
> As we know hash table requires O(N) only.
> There must be so
On 03/18/2010 05:22 AM, Jae Hyuk Kwak wrote:
> On Wed, Mar 17, 2010 at 1:04 PM, Michael Meissner
> wrote:
>> Note, that many hash tables are computed by the modulus operation, which is
>> often fairly expensive (and on machines without a hardware divide unit,
>> requiring a function call). I woul
Dear all,
If anyone is interested, we pre-released new MILEPOST GCC supporting versions
4.4.0,4.4.1,4.4.2 and 4.4.3. You can download it here:
http://sourceforge.net/projects/gcc-ici/files/MILEPOST-GCC/V2.1-pre-release
The new documentation is available here:
http://cTuning.org/wiki/index.php/CT
On Mar 19, 2010, at 12:02 PM, Bruce Korb wrote:
Hi,
What does this message really mean?
i.e. What should I do about it?
ld.so should be loading shared objects in /usr/local/lib,
and that is where libmpc.so lives, so what gives?
Thanks - Bruce
$ cat /etc/SuSE-release
openSUSE 11.1 (x86_64)
V
On 03/19/10 10:47, Ian Bolton wrote:
I mention all this because I was wondering which other architectures
have turned off sched1 for -Os? More importantly, I was wondering
if anyone else had considered creating some kind of clever hybrid
that only uses sched1 when it will increase performance wi
Hi Michael,
Thank you for the detailed response.
On Fri, Mar 19, 2010 at 9:54 AM, Michael Meissner
wrote:
> On Thu, Mar 18, 2010 at 05:10:18PM -0700, Jae Hyuk Kwak wrote:
>> Hi Michael,
>>
>> Thank you for the details.
>> If I understood correctly, your point is that O(log N) is fast enough
>>
Jae Hyuk Kwak wrote:
For the issue of Modulus operation, it does not need to be divide or
hardware modulus operation.
Let me give you an example here:
13 % 2 = 1
13 & (2-1) = 1
Yes, of course, we all know that, and of course the compiler does
these simple optimizations. However, for computing
Hi Robert,
On Fri, Mar 19, 2010 at 2:13 PM, Robert Dewar wrote:
> Jae Hyuk Kwak wrote:
>
>> For the issue of Modulus operation, it does not need to be divide or
>> hardware modulus operation.
>> Let me give you an example here:
>> 13 % 2 = 1
>> 13 & (2-1) = 1
>
> Yes, of course, we all know that
Hi,
I would like to get some advice on handling Android for x86 in
tool configurations. Android is based on Linux but it is exactly the
same, so some customizations are required. There was a discussion
among people working on Android and someone suggested using
i*86-unknown-android. My ques
Jae Hyuk Kwak wrote:
Hi Robert,
On Fri, Mar 19, 2010 at 2:13 PM, Robert Dewar wrote:
Jae Hyuk Kwak wrote:
For the issue of Modulus operation, it does not need to be divide or
hardware modulus operation.
Let me give you an example here:
13 % 2 = 1
13 & (2-1) = 1
Yes, of course, we all know
Hi Bruce,
* Bruce Korb wrote on Fri, Mar 19, 2010 at 05:22:15PM CET:
> On Fri, Mar 19, 2010 at 9:12 AM, Richard Guenther wrote:
> > On Fri, Mar 19, 2010 at 5:02 PM, Bruce Korb wrote:
> >> What does this message really mean?
> >> i.e. What should I do about it?
> >
> > run ldconfig or use binaries
On 19/03/2010 21:13, Robert Dewar wrote:
> Jae Hyuk Kwak wrote:
>
>> For the issue of Modulus operation, it does not need to be divide or
>> hardware modulus operation.
> Yes, of course, we all know that, and of course the compiler does
> these simple optimizations. However, for computing hashes
On Fri, 2010-03-19 at 22:06 +0800, fanqifei wrote:
> 1. I add movsi expander in which function foor_expand_move is used to
> force the operands[1] to reg and emit the move insn.
> Another change is that in the define of insn “*mov_mode_insn" in which
> a condition is added to prevent a store c
On 19/03/2010 22:07, Robert Dewar wrote:
> You miss my point, doing a mod with 256 is an AWFUL hash algorithm
> since it only uses the low order 8 bits!
This statement is only true contingent on a number of significant
assumptions you haven't stated - assumptions which can easily be violated.
On Fri, 19 Mar 2010, Doug Kwan (Ãö®¶¼w) wrote:
> Hi,
>
> I would like to get some advice on handling Android for x86 in
> tool configurations. Android is based on Linux but it is exactly the
> same, so some customizations are required. There was a discussion
> among people working on Androi
On Thu, Mar 18, 2010 at 10:29 AM, roy rosen wrote:
> Hi,
>
> I am trying to implement a simple load 8 bytes instruction.
> I tried to use movdi so that it would allocate two sequential
> registers for the load.
> It starts well but in pass subreg1 the insns are decomposed and all DI
> operands are
Thanks for the fast reply,
On Fri, Mar 19, 2010 at 3:07 PM, Robert Dewar wrote:
>> "In many situations, hash tables turn out to be more efficient than
>> search trees or any other table lookup structure."
>
> The above quote from Wikipedia is indeed misleading because it does
> not make a cleare
That's a very good suggestion. Thanks.
-Doug
2010/3/19 Joseph S. Myers :
> On Fri, 19 Mar 2010, Doug Kwan (Ãö®¶¼w) wrote:
>
>> Hi,
>>
>> I would like to get some advice on handling Android for x86 in
>> tool configurations. Android is based on Linux but it is exactly the
>> same, so some cu
Dave Korn wrote:
Please, nobody bring up the old saw that prime numbers are a good choice for
hashtable sizes. They aren't, they're a crude workaround for a poor hash
function.
Well on a machine with a fast modulus operation, the crude workaround
is often the most efficient algorithm in pra
By the way, in practice I have found that in many situations, the
input to hash functions is nowhere near pseudo-random, e.g. this
is very much true of identifiers in programs, so the best hash
algorithm is often one that is specialized for the particular
non-pseudo-random domain.
Of course in th
Dave Korn wrote:
On 19/03/2010 22:07, Robert Dewar wrote:
You miss my point, doing a mod with 256 is an AWFUL hash algorithm
since it only uses the low order 8 bits!
This statement is only true contingent on a number of significant
assumptions you haven't stated - assumptions which can eas
Jae Hyuk Kwak wrote:
A quote from this article:
" ... the switch very efficiently, even constructing a hash table if this
method of switching is ..."
Yes, it does. Such a old paper mentioned it and we are still not doing it.
So it makes me wonder why.
Why? Perhaps because it is not helpful
Jae Hyuk Kwak wrote:
Now we have a switch statement that has 400 cases or whatever.
switch ( valueFormUser )
{
case 0: do1(); break;
case 1: do2(); break;
case 2: do3(); break;
...
case 399: do399(); break;
default: break;
Well clearly if you have 400 cases like this, perfec
We are glad to announce that GCC has been accepted Google's Summer of
Code 2010 program. Summer of Code is a program sponsored by Google in
which students are paid to contribute to open source projects. This
will be GCC's fifth year of participation. For more information, see
http://code.google.
Hi Ralf,
I used: ../configure && make && make install and that installed it
to /usr/local/lib. However, /usr/local/lib, despite being in /etc/ld.so.conf,
it was not in ld.so.cache. re-running ldconfig did the trick. I've had
/usr/local/lib in the cache for years now, so I don't know how it wen
On Sat, Mar 20, 2010 at 6:24 AM, Jim Wilson wrote:
> On Fri, 2010-03-19 at 22:06 +0800, fanqifei wrote:
>> 1. I add movsi expander in which function foor_expand_move is used to
>> force the operands[1] to reg and emit the move insn.
>> Another change is that in the define of insn “*mov_mode_i
51 matches
Mail list logo
