search for: carruthers

This time with the correct mailing list address... See below... On Wed, Mar 11, 2015 at 3:07 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > Why? > > 1) We're moving away from autoconf already today. We're hoping to drop it > completely soon. > 2) It doesn't work today and no one is complaining. > 3) It hasn't worked for weeks and no one has

The MBlaze backend seems to be essentially unmaintained since 2011. The maintainer (Wesley Peck who is BCC'ed) seems to have vanished, and in fact all emails to him are bouncing. I propose to remove the MBlaze backend on Friday if none step forward as a maintainer. Currently, folks are having to keep it up to date when changing shared parts of the backend with no help. -Chandler

Also, could you patch and test Clang with the Linux kernel after I make this change? I'd like to know that we actually successfully call the correct thunks and that they behave correctly. I'm not super worried, but good to actually get this right. I'm am slightly more worried about the stack-based retpoline than the register ones just due to the overall lower amount of testing

Guys, Just to clarify that with the current fix in SLM there is no need to wait for other issues to be fixed (minor issue). So you can move on with your patch. From: Agabaria, Mohammed Sent: Wednesday, June 07, 2017 15:24 To: Zaks, Ayal <ayal.zaks at intel.com>; Chandler Carruth <chandlerc at gmail.com>; Flamedoge <code.kchoi at gmail.com>; Dehao Chen <dehao at google.com>

FYI, I ran some initial measurements just for sanity on the test-suite on x86-64: Total stack frame size: 13362520 -> 13365864 (+0.02%) Average stack frame size: 581.814 -> 581.96 (+0.02%) Average compile time: 5.71178 -> 5.67256 (within noise) Number of functions is exactly the same, so no trivially visible inlining decision changes. I've spot checked a few of the functions that

Can you say what Benchmark or give a test case so we understand the nature of the regression? As Gerolf said, that will be important to understand what is best to do. On Fri, Jul 17, 2015, 06:43 Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> wrote: > Yes, the regression is stable. I double checked this. A full benchmark > run consists of at least 10 sub-runs to validate the

The patch is up for review here: https://reviews.llvm.org/D42998 On Tue, Feb 6, 2018 at 4:58 PM Chandler Carruth <chandlerc at google.com> wrote: > Also, could you patch and test Clang with the Linux kernel after I make > this change? I'd like to know that we actually successfully call the > correct thunks and that they behave correctly. I'm not super worried, but >

On 7/9/07, Andrew Lenharth <andrewl at lenharth.org> wrote: > Poor alpha, no code examples or entries in your tables. But that said, it uses a load-locked, store-conditional and has various memory barriers which are sufficient to implement all your proposal. Andrew > On 7/9/07, Chandler Carruth <chandlerc at gmail.com> wrote: > > Hello, > > > > After a fair

On Tue, May 30, 2017 at 1:40 AM Agabaria, Mohammed via llvm-dev < llvm-dev at lists.llvm.org> wrote: > We’re seeing nice improvements but also significant degradations on IA, > which we would like to investigate before the patch is committed. > > > > Major degradations we see: > > > > networking > > ip_pktcheckb1m -6.80 % > >

On Mon, Oct 13, 2014 at 4:14 PM, Chandler Carruth <chandlerc at google.com> wrote: > 1. Initialisms. It's common in Clang code (also in LLVM?) to use >> initialisms as variable names. This doesn't really seem to work for names >> that start with a lower case letter. >> > > I think wee at least need a good answer to this. > As I really suspect this is

I have fixed the issue locally, but been out of the office - can apply the fix - or just maintain the makefiles locally if no-one else really wants them, fine with whatever the community decision is. Iain On 11 Mar 2015, at 22:11, Rui Ueyama wrote: > I'd agree, but the Makefiles were added just 9 months ago. I don't know if there's a real need of any kind. Added Iain who added

On Jan 6, 2014, at 11:02 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, Jan 6, 2014 at 1:42 PM, Andrew Trick <atrick at apple.com> wrote: > On Jan 6, 2014, at 10:10 AM, Chandler Carruth <chandlerc at google.com> wrote: > >> Trying to bubble way back to the top, Andy, do you think there is anything else that needs to be done here before it

Before the fix, the compiler may simply return 'noalias' for cases it can not really prove to be noalias, but actually correct by luck (or even wrong noalias, but does not result in miscompile). It would be useful to find out the set of missed noalias queries from GlobalModRef with your benchmark and examine if there is some improvement can be done. David On Fri, Jul 17, 2015 at 6:32

Hi Chandler, I'm still migrating our bots, there were some complications. Can it wait until next week? cheers, --renato On 13 January 2014 22:00, Chandler Carruth <chandlerc at gmail.com> wrote: > FYI, this is happening now-ish! > > > On Tue, Jan 7, 2014 at 1:40 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > >> Greetings, starting a new thread and

On Fri, Jul 17, 2015 at 9:13 AM Evgeny Astigeevich < evgeny.astigeevich at arm.com> wrote: > It’s Dhrystone. > Dhrystone has historically not been a good indicator of real-world performance fluctuations, especially at this small of a shift. I'd like to see if we see any fluctuation on larger and more realistic application benchmarks. One advantage of the flag being set is that we

Right! Can you add a comment to the document review? The other two hooks were good (email, update umbrella), so I think we're set. Cheers, Renato On 20 Jul 2016 12:48 a.m., "Chandler Carruth" <chandlerc at google.com> wrote: > I have already tested protected branches on GitHub successfully and found > it allowed exactly the pushes that were correct -- they must all

Should be fixed in r199756. Let me know. On Tue, Jan 21, 2014 at 10:08 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > Never mind, I see the bug. Working on a fix. > > > On Tue, Jan 21, 2014 at 10:07 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > >> Which version of CMake? >> >> >> On Tue, Jan 21, 2014 at 10:06 AM, Chandler Carruth

On Fri, May 19, 2017 at 4:01 PM Adam Nemet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I will run it on Cyclone/AArch64 next week. > FYI, we're still waiting on these Adam... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170530/7cb390ca/attachment.html>

On Fri, Feb 26, 2016 at 8:57 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ------------------------------ > > *From: *"Xinliang David Li" <xinliangli at gmail.com> > *To: *"Chandler Carruth" <chandlerc at google.com> > *Cc: *"Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" <llvm-dev at lists.llvm.org>, >

Based on function names and structures, this is some version of GCC :) Any way you can post the entire .ll file? Because it's globalsmodref, it's hard to debug without the other functions, since it goes over all the functions to determine address takenness, etc :) On Tue, Jul 21, 2015 at 3:23 PM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > Hi Chandler, > > We