On Mon, Apr 26, 2021 at 11:00 AM Andi Kleen wrote:
> >There are multiple directional changes in this new tool:
> >1) it uses perf-script trace output (in text) as input profile data;
>
> I suspect this will break regularly too
>
> (I personally did numerous changes to perf script output,
On Mon, Apr 26, 2021 at 8:12 AM Andi Kleen wrote:
> Jan Hubicka writes:
> >
> > Is there a way to get this working w/o using older perf?
>
> It's usually rather simple to fix up autofdo for new perf.
> I did it before here
>
> https://github.com/andikleen/autofdo/commits/perf4-3
>
> I think it w
On Sun, Apr 25, 2021 at 12:07 PM Jan Hubicka wrote:
> David,
> >
> > The text format is documented here:
> > https://clang.llvm.org/docs/UsersManual.html
> > The binary format is not documented. The binary format is not guaranteed
> to
> > be backward compatible, so sharing the same format may no
On Fri, Apr 23, 2021 at 12:28 PM Jan Hubicka wrote:
> > On Fri, Apr 23, 2021 at 10:27 AM Xinliang David Li
> > wrote:
> >
> > >
> > >
> > > On Fri, Apr 23, 2021 at 10:16 AM Jan Hubicka wrote:
> > >
> > >> >
> > &
On Fri, Apr 23, 2021 at 10:27 AM Xinliang David Li
wrote:
>
>
> On Fri, Apr 23, 2021 at 10:16 AM Jan Hubicka wrote:
>
>> >
>> > It uses create_llvm_prof tool which is in the same git repo. The data
>> > parsing part is shared with create_gcov, but the wri
On Fri, Apr 23, 2021 at 10:16 AM Jan Hubicka wrote:
> >
> > It uses create_llvm_prof tool which is in the same git repo. The data
> > parsing part is shared with create_gcov, but the writer is obviously
> > different for the two tools.
>
> OK and what are the main differences between llvmand gcc
On Fri, Apr 23, 2021 at 9:54 AM Jan Hubicka wrote:
> > On Fri, Apr 23, 2021 at 12:18 AM Martin Liška wrote:
> >
> > > On 4/23/21 9:00 AM, Richard Biener via Gcc wrote:
> > > > On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc
> > > > wrot
On Fri, Apr 23, 2021 at 12:18 AM Martin Liška wrote:
> On 4/23/21 9:00 AM, Richard Biener via Gcc wrote:
> > On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc
> > wrote:
> >>
> >> Hi, the create_gcov tool was probably removed with the assumption that
&g
On Fri, Apr 23, 2021 at 12:00 AM Richard Biener
wrote:
> On Fri, Apr 23, 2021 at 7:28 AM Xinliang David Li via Gcc
> wrote:
> >
> > Hi, the create_gcov tool was probably removed with the assumption that it
> > was only used with Google GCC branch, but it is actually us
Hi, the create_gcov tool was probably removed with the assumption that it
was only used with Google GCC branch, but it is actually used with GCC
trunk as well.
Given that, the tool will be restored in the github repo. It seems to build
and work fine with the regression test.
The tool may ust work
Resend in plain text mode.
On Wed, Jul 27, 2016 at 9:07 AM, Xinliang David Li wrote:
> Our experience is that non-atomic counter update (the current
> implementation) rarely result in corrupted profile (in heavily threaded
> environment) -- it usually results in some profile insanity
Using AutoFDO is one way. For PGO, you may want to to try using
__gcov_dump interface to explicitly control the timing and order of
the profile dump --- i.e., invoke __gcov_dump in main process after
work processes exit and before the main process exits.
David
On Mon, Jun 1, 2015 at 8:08 PM, Peng
Note that the multi-versioning support is currently only in C++, not in C yet.
David
On Wed, Apr 29, 2015 at 1:24 AM, Christian Bruel wrote:
> Hi Ramana, Richard
>
> After playing with the attritute ((target ("[thumb,arm]")), during the
> pending review, I added the "default" selector to neutral
On Fri, Apr 10, 2015 at 3:43 PM, Jan Hubicka wrote:
>> LBR is used for both cfg edge profiling and indirect call Target value
>> profiling.
> I see, that makes sense ;) I guess if we want to support profile collection
> on targets w/o this feature we could still use one of the algorithms that
> t
On Tue, Apr 7, 2015 at 7:45 AM, Ilya Palachev wrote:
> Hi,
>
> Here are some questions about AutoFDO.
>
> On 08.05.2014 02:55, Dehao Chen wrote:
>>
>> We have open-sourced AutoFDO profile toolchain in:
>>
>> https://github.com/google/autofdo
>>
>> For GCC developers, the most important tool is cre
LBR is used for both cfg edge profiling and indirect call Target value
profiling.
David
On Fri, Apr 10, 2015 at 3:26 PM, Xinliang David Li wrote:
> LBR is used for both cfg edge profiling and indirect call Target value
> profiling.
>
> David
>
> On Apr 10, 2015 10:39 AM, &q
Something seems wrong:
in tree_function_version:
initialize_cfun (new_decl, old_decl,
old_entry_block->count);
>From the above we can see new_decl's entry BB's count will be the same
as old_decl (no scaling).
In copy_bb, new BB's profile count will also be the same as ol
It may be helpful to document the following in msan's official page:
1) success stories (chrome land?)
2) runtime overhead comparison with valgrind
David
On Wed, Oct 1, 2014 at 9:07 AM, Kostya Serebryany wrote:
> [as text for real this time]
> Sanitizer compiler module sizes in LLVM (in lines):
The fix is attached. Ok to commit?
David
On Thu, May 22, 2014 at 9:11 AM, Xinliang David Li wrote:
> I did -- but very likely there was a process error in my side. Will
> fix them soon.
>
> David
>
> On Thu, May 22, 2014 at 2:12 AM, Richard Biener
> wrote:
>> On Th
I did -- but very likely there was a process error in my side. Will
fix them soon.
David
On Thu, May 22, 2014 at 2:12 AM, Richard Biener
wrote:
> On Thu, May 22, 2014 at 10:49 AM, Paolo Carlini
> wrote:
>> Hi,
>>
>> is somebody already working on the regressions which appeared yesterday,
>> see
On Thu, Feb 6, 2014 at 2:21 PM, Tim Prince wrote:
>
> On 2/6/2014 1:51 PM, Uros Bizjak wrote:
>>
>> Hello!
>>
>> 4.9 does not enable -ftree-vectorize for -O3 (and Ofast) anymore. Is
>> this intentional?
>>
>> $/ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -O3 -Q
>> --help=optimizers
>>
>
The invoke.texi is correct. -ftree-vectorize is now simply a
short-hand to enable both loop and slp vectorizer. I will fix the the
help message appropriately.
David
On Thu, Feb 6, 2014 at 11:20 AM, Uros Bizjak wrote:
> On Thu, Feb 6, 2014 at 8:01 PM, Xinliang David Li wrote:
>> It is
It is a bug in the help message dump. You can see that
ftree-loop-vectorize ftree-slp-vectorize are indeed enabled.
David
On Thu, Feb 6, 2014 at 10:51 AM, Uros Bizjak wrote:
> Hello!
>
> 4.9 does not enable -ftree-vectorize for -O3 (and Ofast) anymore. Is
> this intentional?
>
> $/ssd/uros/gcc-b
See also http://gcc.gnu.org/ml/gcc/2013-08/msg00259.html
There are some concerns, but it would be interesting to do some
benchmarking of this.
David
On Tue, Feb 4, 2014 at 8:27 AM, Bingfeng Mei wrote:
> Hi,
> One of biggest issues we have with GCC vectorization is bloated code size.
> For examp
On Thu, Jan 23, 2014 at 2:56 PM, Chris Lattner wrote:
> On Jan 23, 2014, at 12:14 PM, Steven Bosscher wrote:
>> (Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a
>> better-supported point of view.)
>
> Unrelated to this thread, it would be great for this web page to get update
sor is sufficient to guarantee to
> generate loop peeling.
>
> Bingfeng
>
>
> -Original Message-
> From: Xinliang David Li [mailto:davi...@google.com]
> Sent: 15 November 2013 17:30
> To: Bingfeng Mei
> Cc: Richard Biener; gcc@gcc.gnu.org
> Subject: Re: Vectori
The right longer term fix is suggested by Richard. For now you can
probably override the peel parameter for your target (in the target
option_override function).
maybe_set_param_value (PARAM_VECT_MAX_PEELING_FOR_ALIGNMENT,
0, opts->x_param_values, opts_set->x_param_values);
David
On Wed, Sep 18, 2013 at 1:23 PM, Cong Hou wrote:
> First, look as the code below.
>
>
> void foo(int* a, int* b, int n) {
> int i;
> for (i = 0; i < n; ++i)
> a[i] = *b;
> }
>
>
> This loop contains possible aliasing between a[i] and *b, and in order
> to vectorize this loop, GCC p
On Fri, Aug 23, 2013 at 5:16 AM, Richard Biener
wrote:
> Xinliang David Li wrote:
>>Interesting idea!
>
> In the past have already arranged for re-use of the epilogue loop and the
> scalar loop, so the situation was even worse.
>
> Note that re-use prevents complete
; vecb = _mm_loadu_ps(b+i);
> vecc = _mm_loadu_ps(c+i);
> veca = _mm_mul_ps(vecb, vecc);
> _mm_store_ps(a+i, veca);
> }
> m = (i == n) ? n : n+4;
> }
>
> L2:
> for (; i < m; i++)
> a[i] = b[i] * c[i];
> if (i < n)
>
On Thu, Aug 22, 2013 at 1:24 AM, Ondřej Bílka wrote:
> On Wed, Aug 21, 2013 at 11:50:34PM -0700, Xinliang David Li wrote:
>> > The effect on runtime is not correlated to
>> > either (which means the vectorizer cost model is rather bad), but integer
>> > code u
> The effect on runtime is not correlated to
> either (which means the vectorizer cost model is rather bad), but integer
> code usually does not benefit at all.
The cost model does need some tuning. For instance, GCC vectorizer
does peeling aggressively, but peeling in many cases can be avoided
w
congrats!
David
On Tue, Aug 20, 2013 at 12:24 PM, Steven Bosscher wrote:
> On Sun, Aug 11, 2013 at 10:04 PM, Gerald Pfeifer wrote:
>> It's my pleasure to announce the appointment of Steven Bosscher
>> as RTL optimizers reviewer.
>>
>> Congratulations and Happy Hacking, Steven!
>>
>> Gerald
>>
>>
On Tue, Aug 20, 2013 at 3:59 AM, Richard Biener
wrote:
> Xinliang David Li wrote:
>>On Mon, Aug 19, 2013 at 11:53 AM, Richard Biener
>> wrote:
>>> Xinliang David Li wrote:
>>>>+cc auto-vectorizer maintainers.
>>>>
>>>>Davi
On Mon, Aug 19, 2013 at 11:53 AM, Richard Biener
wrote:
> Xinliang David Li wrote:
>>+cc auto-vectorizer maintainers.
>>
>>David
>>
>>On Mon, Aug 19, 2013 at 10:37 AM, Cong Hou wrote:
>>> Nowadays, SIMD instructions play more and more important roles i
+cc auto-vectorizer maintainers.
David
On Mon, Aug 19, 2013 at 10:37 AM, Cong Hou wrote:
> Nowadays, SIMD instructions play more and more important roles in our
> daily computations. AVX and AVX2 have extended 128-bit registers to
> 256-bit ones, and the newly announced AVX-512 further doubles t
On Mon, Aug 5, 2013 at 12:16 PM, Steven Rostedt wrote:
> On Mon, 2013-08-05 at 12:04 -0700, Andi Kleen wrote:
>> Steven Rostedt writes:
>>
>> Can't you just use -freorder-blocks-and-partition?
>
> Yeah, I'm familiar with this option.
>
This option works best with FDO. FDOed linux kernel rocks
On Wed, Jul 10, 2013 at 2:37 PM, Manuel López-Ibáñez
wrote:
>> This points to other ideas:
>> 1) how about adding a helper switch to show what is included in Wall?
>> such as -Wall-print
>
> Doesn't
>
> gcc -Q -Wall --help=warnings
>
> give you this?
>
Yes it does work as expected.
> Otherwise,
On Wed, Jul 10, 2013 at 1:20 PM, Gabriel Dos Reis
wrote:
> On Wed, Jul 10, 2013 at 2:49 PM, Xinliang David Li wrote:
>> There are two fundamental problems:
>> 1) uninit warning has false positives.
>> 2) people disagree what is the expected behavior of -Wall.
>>
behavior of -Wall, or ask concerned user to
explicitly use -Wno-error=... or white list the warning options they
care.
David
On Wed, Jul 10, 2013 at 12:36 PM, Gabriel Dos Reis
wrote:
> On Wed, Jul 10, 2013 at 2:27 PM, Xinliang David Li wrote:
>> On Wed, Jul 10, 2013 at 12:05 PM, Gabriel
On Wed, Jul 10, 2013 at 12:05 PM, Gabriel Dos Reis
wrote:
> On Wed, Jul 10, 2013 at 2:01 PM, Xinliang David Li wrote:
>> What about introducing a new blanket warning kind that excludes
>> anything with false positives? something like -WALL ?
>
> I am doubtful "
What about introducing a new blanket warning kind that excludes
anything with false positives? something like -WALL ?
David
On Wed, Jul 10, 2013 at 3:51 AM, Andreas Arnez wrote:
> Jeff Law writes:
>
>> On 07/09/2013 07:56 AM, Andreas Arnez wrote:
>>> Andrew Haley writes:
>>>
On 07/09/2013
Please repost the patch to gcc-patches@ mailing list.
David
On Tue, Jul 9, 2013 at 1:10 PM, Cong Hou wrote:
> Hi
>
> My name is Cong Hou, and I am a Noogler working in the compiler
> optimization team at Google.
>
> When we were trying moving the vectorization from O3 to O2 in GCC 4.9,
> we met
yes, loop vectorizer relies on early passes to straighten out control
flow (unswitch, index splitting, loop distribution, ifcvt etc). Intel
ICC is pretty good at it. For the following simple made up case, icc
vectorizes the loop.
int a[1];
int b[1];
int foo (int n)
{
int i;
for (i
On Fri, May 31, 2013 at 6:54 AM, Jakub Jelinek wrote:
> On Fri, May 31, 2013 at 03:48:59PM +0200, Toon Moene wrote:
>> >If you rewrite the above into:
>> >SUBROUTINE XYZ(A, B, N)
>> >DIMENSION A(N), B(N)
>> >DO I = 1, N
>> >C = B(I)
>> >IF (A(I)> 0.0) THEN
>> > A(I) = C / A(I)
>> >
There is a similar patch (in google branches) from Rong Xu which
enables atomic profile counter update.
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00072.html
On Mon, Apr 22, 2013 at 12:59 PM, Bill Schmidt
wrote:
> Six years ago, Michael Matz proposed a patch for generating profile
> instrument
How about finding the single-entry/single exit region that dominates
the switch and post-dominates the s assignment. You can then examine
if s is modified in the region.
David
On Fri, Mar 22, 2013 at 10:17 AM, Steve Ellcey wrote:
> I am looking at implementing a GCC optimization pass based on c
On Fri, Feb 22, 2013 at 3:08 PM, Easwaran Raman wrote:
> Hi,
>
> Consider the following function
>
> A *CheckNotNull (A *a_ptr) {
> if (a_ptr == NULL) {
> // Code with non-trivial code size
> }
> return a_ptr;
> }
>
> If this is invoked as CheckNotNull(&a), the inliner should be able to
On Thu, Feb 7, 2013 at 9:28 AM, David Edelsohn wrote:
> On Thu, Feb 7, 2013 at 11:09 AM, Richard Biener
> wrote:
>
>> Also note that for SPEC -funroll-loops helps GCC (yes ... we don't
>> enable that by default at -O3, we probably should).
>
> Richi,
>
> Are you suggesting enabling -funroll-loops
A related discussion in this thread:
http://gcc.gnu.org/ml/gcc/2013-01/msg00215.html
On Fri, Jan 18, 2013 at 7:57 AM, Miles Bader wrote:
> Richard Biener writes:
>> Note that combine does not apply because %eax is used multiple
>> times. This also means that for code-size the combining is not a
>> Or better way to solve the problem? Appreciated a lot!
>
> Combine / simplify-rtx should recognize this at the RTL level for
> SHIFT_COUNT_TRUNCATED targets.
IIUC, combine uses UD chains (LOG links) which is best suitable for
cases where this is only one downward uses of the def. The example
he
[cc list trimmed]
On Wed, Jan 16, 2013 at 5:44 PM, Wei Mi wrote:
> Hi,
>
> For x86, shift insn will automatically mask the count to 5 bits in 32
> bit mode and to 6 bits in 64 bit mode, so for the testcase below, the
> buf_ << (-end & 63) could be optimized to buf_ << -end. But for trunk
> compi
What you described is the 'transitional model' right? but I don't see
any of those in the C++ standard working paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf
David
On Tue, Nov 27, 2012 at 11:07 PM, Chris Lattner wrote:
>
> On Nov 27, 2012, at 11:
On Tue, Nov 27, 2012 at 10:40 PM, Chris Lattner wrote:
>
> On Nov 27, 2012, at 9:08 PM, Miles Bader wrote:
>
>> Chris Lattner writes:
>>> Clang has fantastic support for PCH... and soon modules. We don't
>>> plan to drop PCH support when modules is implemented.
>>
>> Do you have a pointer to th
On Tue, Nov 27, 2012 at 4:11 PM, Chris Lattner wrote:
>
> On Nov 27, 2012, at 3:32 PM, Eric Botcazou wrote:
>
>>> I admit that I'm partly fishing here, but my proposal is based on the
>>> following:
>>>
>>> * The implementation of PCH in GCC is atrocious and hard to maintain.
>>> * The next C++ s
On Sun, Nov 25, 2012 at 7:45 AM, Richard Biener
wrote:
> On Sun, Nov 25, 2012 at 4:21 PM, Diego Novillo wrote:
>> On Sun, Nov 25, 2012 at 10:09 AM, Richard Biener
>> wrote:
>>
>>> I'd say the most pragmatic solution is to stick with gengtype but
>>> make it more dependent on annotations (thus, e
const A& a) { os <<
a.i << endl ; }
__attribute__((noinline)) void operator<< (ostream& os, const A& a)
{
os << a.i << endl;
}
int main()
{
A a;
cout << a;
print (cout, a);
On Tue, Nov 20, 2012 at 4:37 PM, Lawrence Crowl wrote:
>
one minus -- less gdb friendly.
David
On Tue, Nov 20, 2012 at 4:16 PM, Lawrence Crowl wrote:
> On 11/20/12, Diego Novillo wrote:
>> On Nov 20, 2012 Basile Starynkevitch wrote:
>> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
>> > > function (FILE *, item_to_dump, formatting
This can be simplified further -- there should be one print method for
every class/struct entity as a member method
enum print_flags
{
print_pretty = 0x1,
print_decl_only = 0x2,
print_raw = 0x4,
..
};
class bitmap {
public:
void print_me (print_flags flags = print_pretty, FI
On Sat, Nov 17, 2012 at 12:35 AM, Basile Starynkevitch
wrote:
> On Fri, Nov 16, 2012 at 07:44:12PM -0800, Xinliang David Li wrote:
>> >
>> >
>> > My strong belief is that a compiler project as gigantic as GCC needs some
>> > kind
>> > of garbag
>
>
> My strong belief is that a compiler project as gigantic as GCC needs some kind
> of garbage collection
Can you name another compiler written in C/C++ using GC ? :)
>. I also believe that the current (4.7) garbage
> collection *implementation* (which is probably what both Diego and
> Lawrenc
On Fri, Nov 16, 2012 at 5:13 AM, Diego Novillo wrote:
> On Thu, Nov 15, 2012 at 2:31 AM, Xinliang David Li wrote:
>
>>> ssa_stmt t = q.stmt (NE_EXPR, shadow, 0);
>>> ssa_stmt a = q.stmt (BIT_AND_EXPR, base_addr, 7);
>>> ssa_stmt b = q.stmt (shadow_type, a);
>
On Thu, Nov 15, 2012 at 9:01 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 15 Nov 2012, Gabriel Dos Reis wrote:
>
>> On Thu, Nov 15, 2012 at 8:48 AM, Michael Matz wrote:
>> [...]
>> > The method name should imply the action, e.g. 'add_stmt' or append_stmt
>> > or the like.
>>
>> strongly agreed.
>> [
On Wed, Nov 14, 2012 at 5:13 PM, Lawrence Crowl wrote:
> Diego and I seek your comments on the following (loose) proposal.
>
>
> Generating gimple and tree expressions require lots of detail,
> which is hard to remember and easy to get wrong. There is some
> amount of boilerplate code that can, i
GCC has the -Winit-self warning.
David
On Fri, Nov 9, 2012 at 12:18 PM, Bruno Nery wrote:
> Howdy,
>
> The following piece of code:
>
> === snip ===
> #include
>
> struct warnme
> {
> bool member_;
> warnme(bool member) : member_(member_) {}
> };
>
> int main()
> {
> warnme wm(true)
Asan functionality is almost complete. The only missing feature is the
handling of bit-fields. In addition there is the need for some option
and attribute change, but those are minor. I think it is now a good
time to merge the functionality into trunk. After that, more
extensive testings can be d
Dear steering committee,
To support address-sanitizer feature:
http://code.google.com/p/address-sanitizer/ in gcc, we need to drop in
a foreign library into gcc repository. The attached is the README.gcc
and a copy of the license file. A sample library source file head is
also shown here. Does it
The one taking argument is changed to dump_enabled_phase (Sharad,
should it be dump_enabled_phase_p ?).
Sharad, it may be better to throwing first a trivial patch that
introduces dump_enabled_p () without argument, and leave the clean up
of vectorizer code as a separate one. Do this earlier so tha
sounds good.
thanks,
David
On Thu, Oct 18, 2012 at 1:52 AM, Richard Biener
wrote:
> On Wed, Oct 17, 2012 at 6:55 PM, Xinliang David Li wrote:
>> On Wed, Oct 17, 2012 at 2:08 AM, Richard Biener
>> wrote:
>>> On Wed, Oct 17, 2012 at 9:05 AM, Xinliang David Li
>&g
On Wed, Oct 17, 2012 at 1:40 PM, Sharad Singhai wrote:
> On Tue, Oct 16, 2012 at 11:17 PM, Georg-Johann Lay wrote:
>
>> How are dumps from the backend handled then?
>
> I haven't really looked at backends. Perhaps they can be converted at
> the cost of extra dispatch functions defined in dumpfile
On Wed, Oct 17, 2012 at 2:08 AM, Richard Biener
wrote:
> On Wed, Oct 17, 2012 at 9:05 AM, Xinliang David Li wrote:
>> A more simpler use model is not to guard the dump statement at all --
>> just express the intention a) what to dump; b) as what kind or to
>> where
>>
A more simpler use model is not to guard the dump statement at all --
just express the intention a) what to dump; b) as what kind or to
where
1) I want to dump the something as optimized message:
dump_printf (MSG_OPTIMIZED, "blah...")
dump_printf_loc (MSG_OPTIMIZED, "blah")
2) I want to du
Somewhere it is mentioned that heap is handled conservatively. Does it
mean the algorithm can not disambiguate heap objects all all, or it
can but does not track pointer values stored in heap objects?
How about field sensitivity? For many programs (mostly C++ ones), this
is very important.
For CS
On Fri, Oct 5, 2012 at 1:12 PM, Jason Merrill wrote:
> On 10/05/2012 03:46 PM, Xinliang David Li wrote:
>>
>> 1) As mentioned in this thread -- when the wrapper is inlined, the
>> pure attribute will be lost. It will give compiler hard time to
>> optimize away the g
The semantics of the 'first' reference of the TLS variable has
changed, and this change is introduced by the implementation. It is no
longer safe to do DCE as
thread_local int x = ..;
int foo()
{
x;
...
}
but should be safe to do DSE as
int foo()
{
x = ...; // Dead
x = ...;
..
}
It would be nice to have a complete tsan/asan implementation for 4.8
-- IMHO it is one of the major missing (popular) features in gcc, so
the earlier gcc has it the better.
Killing mudlap is a completely different goal which does not have to
be tied to this release.
The question is that since asa
On Wed, Sep 5, 2012 at 10:14 PM, Jan Hubicka wrote:
>> On Wed, Sep 5, 2012 at 5:41 PM, Lawrence Crowl wrote:
>> > On 9/5/12, Xinliang David Li wrote:
>> >> On Sep 5, 2012 Jan Hubicka wrote:
>> >> > OK, the basic idea is that symtab_node is basetype of
On Wed, Sep 5, 2012 at 9:38 PM, Jan Hubicka wrote:
>> > On 9/5/12, Xinliang David Li wrote:
>> > > On Sep 5, 2012 Jan Hubicka wrote:
>> > > > OK, the basic idea is that symtab_node is basetype of
>> > > > cgraph_node and varpool_node. We may
On Wed, Sep 5, 2012 at 9:32 PM, Jan Hubicka wrote:
>> On 9/5/12, Xinliang David Li wrote:
>> > On Sep 5, 2012 Jan Hubicka wrote:
>> > > OK, the basic idea is that symtab_node is basetype of
>> > > cgraph_node and varpool_node. We may want to drop the his
On Wed, Sep 5, 2012 at 5:41 PM, Lawrence Crowl wrote:
> On 9/5/12, Xinliang David Li wrote:
>> On Sep 5, 2012 Jan Hubicka wrote:
>> > OK, the basic idea is that symtab_node is basetype of
>> > cgraph_node and varpool_node. We may want to drop the historica
>> &
On Wed, Sep 5, 2012 at 3:47 PM, Jan Hubicka wrote:
>> What do you think of the following plan for turning cgraph into
>> a class hierarchy? We cannot finish it until we have gengtype
>> understanding single inheritance, but we can start changing APIs
>> in preparation.
>
> Good you told me, I was
On Thu, Apr 12, 2012 at 3:28 PM, Jonathan Wakely wrote:
> On 12 April 2012 22:53, Xinliang David Li wrote:
>> yes ..
>
> Excellent, thanks, and thanks for the link to the pdf, I hadn't seen
> it before and GCC does do pretty poorly with those examples.
The talk wa
yes ..
thanks,
David
On Thu, Apr 12, 2012 at 2:51 PM, Jonathan Wakely wrote:
> On 12 April 2012 22:32, Xinliang David Li wrote:
>> Thanks for preparing the wiki page. I have looked at the examples from
>> this slide: http://ecn.channel9.msdn.com/events/GoingNative12/GN12Clang.pd
Thanks for preparing the wiki page. I have looked at the examples from
this slide: http://ecn.channel9.msdn.com/events/GoingNative12/GN12Clang.pdf
with trunk gcc. In some cases, gcc's warning matches that of clang but
in majority of cases, gcc either emits no warnings or worse ones. The
warnings in
On Wed, Apr 11, 2012 at 11:37 AM, Basile Starynkevitch
wrote:
> On Wed, 11 Apr 2012 10:30:36 -0700
> Xinliang David Li wrote:
> [..]
>>
>> yes -- GCC is not considered old and not 'cool' -- so it is hard to
>> advertise. One criteria to see GCC's future
On Wed, Apr 11, 2012 at 11:17 AM, Andrew Pinski wrote:
> On Wed, Apr 11, 2012 at 10:24 AM, Xinliang David Li
> wrote:
>> On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther
>> wrote:
>>> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel wrote:
>>>> On
On Wed, Apr 11, 2012 at 11:26 AM, Jonathan Wakely wrote:
> On 11 April 2012 18:24, Xinliang David Li wrote:
>>
>> Yes, GCC is still in some comfortable zones such as generated code
>> quality, performance, etc, but the advantage and gap is quickly
>> reducing (e.g, LLVM
On Wed, Apr 11, 2012 at 7:44 AM, David Edelsohn wrote:
> On Wed, Apr 11, 2012 at 9:28 AM, Jakub Jelinek wrote:
>> On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote:
>>> The reason why I am mystified is that the people who seem to argue
>>> that it would be pointless to convert the
On Wed, Apr 11, 2012 at 6:21 AM, Bernd Schmidt wrote:
> On 04/11/2012 02:57 PM, Torvald Riegel wrote:
>> However, the concern you raised is only one part of the problem. The
>> other is that, put in a simplified way, GCC is competing with LLVM about
>> new and/or non-fulltime-compiler developers.
On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther
wrote:
> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel wrote:
>> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel wrote:
>>> > Think about programmers new to GCC for a second, and ab
On Wed, Apr 11, 2012 at 5:57 AM, Torvald Riegel wrote:
> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel wrote:
>> > Think about programmers new to GCC for a second, and about code
>> > completion tools.
>>
>> Honestly I care 1000 time
On Wed, Apr 11, 2012 at 5:47 AM, Richard Guenther
wrote:
> On Wed, Apr 11, 2012 at 2:34 PM, Bernd Schmidt
> wrote:
>> On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
>>> I have been having difficulty following the twists and the turns and
>>> the goal post moving.
>>> Are you essentially requiri
Mostly agreed. In particular, the discussions should be more concrete
-- instead of voting on moving everything to C++ which can create a
huge chaos, we should first carefully partition the components that
are candidates for the migration (as mentioned by Richard). For
instance,
1) core APIs
a)
On Wed, Apr 11, 2012 at 5:43 AM, Marek Polacek wrote:
> On Tue, Apr 10, 2012 at 10:54:01AM -0700, Xinliang David Li wrote:
>> manipulation -- be it C or C++. However I think this is really more
>> about the general perceptions and how future developers feel about it.
>
> If G
On Wed, Apr 11, 2012 at 2:43 AM, Richard Guenther
wrote:
> On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl wrote:
>> On 4/10/12, Jakub Jelinek wrote:
>>> That when stepping through code in the debugger you keep
>>> enterring/exiting these one liner inlines, most of them really
>>> should be at l
On Wed, Apr 11, 2012 at 2:16 AM, Richard Guenther
wrote:
> On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo wrote:
>> On 4/10/12 12:05 PM, Gabriel Dos Reis wrote:
>>>
>>> On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn
>>> wrote:
>>>
Also, it will be more convenient to make this change incre
On Tue, Apr 10, 2012 at 9:39 AM, Jakub Jelinek wrote:
> On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote:
>> On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek wrote:
>> > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>> >> Class
On Tue, Apr 10, 2012 at 9:24 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Xinliang David Li wrote:
>
>> >> > exp->as_component_ref().get_field() ..
>
>> > Actually it's not questionable. The above stuff is _horrible_.
>&g
On Tue, Apr 10, 2012 at 4:14 AM, Richard Guenther
wrote:
> On Tue, Apr 10, 2012 at 1:34 AM, Xinliang David Li wrote:
>> On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther
>> wrote:
>>> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt
>>> wrote:
>>>> O
On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek wrote:
> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>> Class hierarchy is one such feature that is useful. Assuming we have
>> two hierarchies for gcc: one for values rooted at ValExp, and one for
>> g
1 - 100 of 193 matches
Mail list logo
