- which also includes some other profile related enhancements
mentioned in:
http://gcc.gnu.org/wiki/ProfileFeedbackEnhancements
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
lated aspect).
I liked the following paper (for general users,
not for the compiler developers, mind you):
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
implementation can't,
as long as it claims any conformity to IEC 60559.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
"Seongbae Park" <[EMAIL PROTECTED]> writes:
> On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
>> -O2 does not currently imply '-ffast-math'ish optimizations even
>> though the C st
ever, not all C99 conformant compiler aren't LIA-1 conformant.
C isn't conformant to LIA-1 but merely compatible,
exactly because of the undefined aspect.
That's enough playing a language laywer for me in a day.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
rop in performance across almost all the benchmarks
on Dec 30, including popular programs like bzip2 and gzip.
Also, this is only on x86 -
other targets that benefit more from software pipelinine/modulo scheduling
may suffer even more than x86, especially on the FP side.
--
#pragma ident "Seongb
I will make that change.
I remember someone wanting to provide his own mcount().
Presumably, mcount() is weak in libc to cover such a use case ?
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
tion to remove such sections.
So if you want to propose a solution for that, I think you should
consider how it can be used for debugging information as well. And I
don't think SHF_DISCARD is a good name. We don't want to arbitrarily
discard the data, we want to discard it in certain specific scenarios.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
e the default behavior
of ignoring the integer overflow at high optimization level
(see their documentation about +Ointeger_overflow= flag).
IBM xlc has very similar approach, IIRC.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
ted).
Based on my understanding, the topic might be of interest
to some other people as well.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
or some easily fixable things that we haven't gotten to yet.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
please explain to me why it is so ?
I am attaching the VCG representation, the VCG text file, and the original
test program..
Thank You
sunzir
I don't know what kind of vcg viewer/converter you're using,
but set it to ignore class 3 edges - you'll get what you expe
L problem ?
I doubt "can't combine" is the real immediate symptom,
as it's most likely just a dump of rld[].nocombine.
Show us at least your error message and the rtl
that you think is causing the problem.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
presented the way described above}
would transform it to
for (p = q, i = 0; p < q + 100; p++, i++)
{base = q, offset = offsetof(x), indices: lower = 0 upper = ? step =
sizeof (*p) value = i}
so that dependence analysis and friends do not have to distinguish
betwe
erences seemed unimportant.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
causes approved :).
Which can be found at:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01746.html
Thanks,
Andrew Pinski
Thanks for the plug, Andrew.
C++ maintainers,
Please consider this as another ping for my patch :)
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
On 5/2/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Seongbae Park wrote:
> On 5/1/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>> On 01 May 2007 14:28:07 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> > I agree that it would be appropriate to backp
lem is to use -ffloat-store
but you'll suffer the performance penalty and it won't really fix
the root cause - which is your code.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
rs will try to accomodate it,
but IMHO this one (bug 323) isn't such.
[1] by implementation, I mean the combination of:
microprocessor, OS, compiler and runtime libraries..
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
uction selection.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
when a double is passed on the stack.
I don't know enough about gcc's gc to know whether the above can trip it over,
but the memory allocation (malloc and the likes) shouldn't be a
problem as long as
it returns 8-byte aligned block on 32bit and 16-byte aligned on 64bit.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
pushl %ebp
movl%esp, %ebp
movl[EMAIL PROTECTED], %eax
movl%gs:(%eax), %eax
leave
ret
.Lfe2:
.size func2,.Lfe2-func2
.ident "GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"
#
--
#pragma ident &quo
On 7/2/06, Gary Funck <[EMAIL PROTECTED]> wrote:
...
Seongbae Park wrote:
> Because the compiler has to generate different code
> for accesses to __thread vs non __thread variable
In my view, this is implementation-defined, and generally can vary
depending upon the underlying l
latform
should be a matter of discussion, and whether or not that patch will be
accepted in the mainline will be yet another.
Because of the reasons I said above, I think it's a bad idea in general
and I'll oppose to it for any of platforms I care about.
--
#pragma
On 7/3/06, Gary Funck <[EMAIL PROTECTED]> wrote:
Seongbae Park wrote:
> As I said, you're welcome to implement a new option
> (either a runtime option or a compile time configuration option)
> that will allow mixing TLS vs non-TLS.
In a way, we've already done t
tically equivalent to:
int __thread local_counter;
int global_counter;
in C99 w/ __thread extension.
Your proposal is equivalent, in UPC, like allowing
declaring a global variable as private, and then later
turn it into a shared in the definition, or vice versa.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
t.
Also some of the datum are encoded as uleb128
(see dwarf spec for the detail of LEB128 encoding)
which is a variable-length encoding whose length depends on the value.
In short, you'd better start looking at how CIE/FDE structures are *logically*
layed out - otherwise you won't be able to generate correct entries.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
eadonly data is manageable,
you can do this by hand -
inspect what the layout of the class is by writing a test program
and looking at how the fields are layed out,
and replicating the same data in the assembly.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
rement compared against the "end" pointer
which happens often in string manipulation or buffer management code.
More importantly some of C++ STL iterators often end up in such a form.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
separates the encoding/decoding from the rest of the compilation,
we can throw away and recompute certain information
(e.g. often certain control flow graph can be recovered,
hence does not need to be encoded)
but those details can be worked out as the implementation of the IO interface
gets more in sh
r merging by linker,
then debugger may not be able to tell what is the real type of the pointer,
and you'll get "impossible" stack traces, etc).
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
On Mon, Dec 15, 2008 at 2:20 PM, David Meggy wrote:
> Hi, I'm working on a very embedded project where we have no operating
> system, and there is no window overflow trap handler. I'm really
> stretched for memory and I'd like to reduce the stack size. I haven't
> not being able to find anyone e
This is the intended behavior, though now I see that the documentation
isn't very clear.
You need to use -fprofile-use - the typical usage scenario is to
compile with -fprofile-generate
to build an executable to do profile collection, and then compile with
-fprofile-use
to build optimized code usin
On Thu, Jan 8, 2009 at 10:11 AM, Hariharan wrote:
> Hi Seongbae,
> Does that mean that someone cant use the profile just to annotate branches
> (and get better code by that), without having to get the additional baggage
> of "unroll-loops", "peel-loops" etc?
You can do that by selectively turning
On Wed, Feb 27, 2008 at 5:16 PM, Andrew Hutchinson
<[EMAIL PROTECTED]> wrote:
> Register saves by prolog (pushes) are typically made with reference to
> "df_regs_ever_live_p()" or "regs_ever_live. "||
>
> If my understanding is correct, these calls reflect register USEs and
> not register DEFs
ed.
> This is true even if function is not a leaf function (as same register
> would be preserved by deeper calls)
>
>
> Andy
>
>
>
>
>
> Seongbae Park (박성배, 朴成培) wrote:
> > On Wed, Feb 27, 2008 at 5:16 PM, Andrew Hutchinson
> > <[EMAIL PROTECT
2008/3/1 Andrew Hutchinson <[EMAIL PROTECTED]>:
> I'm am still struggling with a good solution that avoids unneeded saves
> of parameter registers.
>
> To solve problem all I need to know are the registers actually used for
> parameters. Since the caller assumes all of these are clobbered by
>
On Thu, Mar 13, 2008 at 11:31 AM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Moving on the SPARC, I see a lot of similar
> unsupported instruction failures. I only
> see a single sparc feature test. It is for
> "-multrasparc -mvis" and it is actually
> passing on the sparc instructio
2008/3/13 Joel Sherrill <[EMAIL PROTECTED]>:
>
> Seongbae Park (박성배, 朴成培) wrote:
> > On Thu, Mar 13, 2008 at 11:31 AM, Joel Sherrill
> > <[EMAIL PROTECTED]> wrote:
> >
> >> Hi,
> >>
> >> Moving on the SPARC, I see a lot of simi
On Thu, Mar 13, 2008 at 12:32 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
>
> Uros Bizjak wrote:
> > Hello!
> >
> >
> >> Can someone familiar with VIS provide an instruction
> >> that is OK to do a run-time test with to check if
> >> it is supported?
> >>
> >
> > Perhaps this fragment fro
assed to the DImode left-shift library function
__lshrdi3. From the dump-file it seems the first pass it is
lost, is combine.
Let me know if I can be of help.
brgds, H-P
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
ow merge happens.
Thanks,
Seongbae
On 6/10/07, Seongbae Park (박성배, 朴成培) <[EMAIL PROTECTED]> wrote:
Thanks for the detailed instruction on how to reproduce it
- I have successfully reproduced the problem, and narrowed it down
to combine that's deleting the insn in question.
Hopefully I&#
t a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
specmake: *** [combine.o] Error 1
Sounds like there's a pass that are emitting a barrier during cfglayout mode.
I'll look at them.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
change to gcse that
> should have fixed this bug.
These two are gone now. The ia64 miscompares still are there.
I'm looking at it. It is either a scheduler problem,
or some other problem downstream triggered by the scheduler.
However, I'm having hard time adding fine-grained dbg_cnt to our scheduler
- do you know who might be interested in adding insn level
dbg_cnt in the scheduler ? Current dbg_cnt (sched_insn) causes ICE :(
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Forwarding to gcc@, as this might be interesting to other people,
and I'd like to ask whoever working on ia64 to take this issue up.
Seongbae
-- Forwarded message --
From: Seongbae Park (박성배, 朴成培) <[EMAIL PROTECTED]>
Date: Jun 18, 2007 12:44 AM
Subject: INCOMING_RETU
reg is a virtual_stack_reg?
FIRST_VIRTUAL_REGISTER <= regno <= LAST_VIRTUAL_REGISTER
--
Rask Ingemann Lambertsen
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
nk you
sunzir
See gcc/graph.c:print_rtl_graph_with_bb().
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
binary search on "n"
by adding the following extra flag to the compilation line:
-fdbg-cnt=uncprop_at_func:n
or
-fdbg-cnt=dominator_at_func:n
Of course, once you narrowed it down to that level,
you'll most likely still need to narrow it down further
but you'll have a better chance (you may want to add
another more fine grained dbgcnt for that).
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
t; .50.compgotos.vcg
So basically I want to assume the maximum vcg file that is created
is a function of the optimizations and not a function of the source file..
Why?
There's no guarantee,
although usually on any particular version of gcc on a given platform
with given options, probab
ompiler
they maintain,
they still need approval of their own patches from other maintainers
or reviewers.
> Write After Approval(last name alphabetical
> order)
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
On 8/17/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
...
> we should talk. I am avail today. i am leaving on vacation tomorrow
> for a week.
Please send me the patch before you leave (and please leave valinor
turned on) - I'll give a look while you're gone.
--
#pragm
en a PR and assign it to me, if you're not in a hurry -
I should be able to look at it next week.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
On 9/27/07, Hariharan Sandanagobalane <[EMAIL PROTECTED]> wrote:
> Hello,
> I am implementing support for PBO on picochip port of GCC (not yet
> submitted to mainline).
>
> I see that GCC generates 2 files, xx.gcno and xx.gcda, containing the
> profile information, the former containing the flow gr
On 10/5/07, Hariharan Sandanagobalane <[EMAIL PROTECTED]> wrote:
>
>
> Seongbae Park (???, ???) wrote:
> > On 9/27/07, Hariharan Sandanagobalane <[EMAIL PROTECTED]> wrote:
> >> Hello,
> >> I am implementing support for PBO on picochip port of GCC (not
quot; (&var));
> return ret + regval;
> }
>
> void func(void **pp)
> {
> int i;
>
> for (i = 0; i < 56; i++) {
> cond_resched();
> *pp = expression(regval);
> }
> }
loop-invariant.cc uses ud-chain.
So if there's something wrong with the chain,
it could go nuts.
Can you send me the rtl dump of loop2_invariant pass ?
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
On 10/16/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 21:53:37 -0700
>
> Annyoung haseyo, Park-sanseng-nim,
:)
> > loop-invariant.cc uses ud-chain.
> > So if there
nters (and long's)
> is as good a specification as any.
>
> RFCs,
>
> Darryl
More appropriate comparison is probably against MIPS,
with their two 32-bit ABIs (O32 and N32 ABI).
Essentially you're asking for N32 equivalent.
My bet is that most people simply don't care enough about
the performance differential.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
On 10/19/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
> Date: Fri, 19 Oct 2007 17:25:14 -0700
>
> > If you're not in a hurry, can you wait
> > till I run the regtest against 4.2 on x86-64 ?
On 10/19/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 22:56:49 -0700
>
> > Did you replace the DF_REF_REG_USE with DEF ?
> > If so, that's not correct. We need to add DE
Hi Dave,
On x86-64, no regression in 4.2 with the patch.
So both 4.2 and mainline patches are OK.
I'd appreciate it if you can add the testcase
- it's up to you whether to add it in a separate patch or with this patch.
Thanks for fixing it.
Seongbae
On 10/19/07, Seongbae Park
On 10/24/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> While testing a patch for the SMS I got an ICE which seems
> to be related to the fact we build def-use chains only
> and not use-def chains. (removed in the following patch -
> http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01682.
On 10/24/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
> > > The problem arises when we delete an insn from the df that contains a
> > > use but do not update the def-use chain of it's def as we do not have
> > > the use-def chain to reach it's def, This later causes a problem when
> > > we try to d
> > > information outside the IL. I argued against a specific
> > > implementation--DEBUG_INSN--based on our experience with similar
> > > implementations.
> >
> > Do you remember any other notes that contained actual rtx expressions
> > and expected optimization passes to keep them accurate?
>
> No.
>
> > Do you think
> > we'd gain anything by moving them to a separate, out-of-line
> > representation?
>
> I don't know. I don't see such a proposal on the table, and I don't
> have one myself, so I don't know how to evaluate it.
>
> Ian
>
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
64 matches
Mail list logo
