similar to: Clang anyone ?

Hello all, We are students from Indian Institute of Technology(IIT), Hyderabad, we would like to propose the addition of the following pragmas in LLVM that aide in (or possibly increase the scope of) vectorization in LLVM (in comparison with other compilers). 1. ivdep 2. Nontemporal 3. [no]vecremainder 4. [no]mask_readwrite 5. [un]aligned Could you please

> On Dec 6, 2017, at 9:00 AM, mats petersson via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > In my experience, a lot of time is spent on optimizing the code (assuming it's not a "-O0" build). The numbers were actually for the debug build (-O0 -g), so for Release build they would be different (presumably lower). > Also redundant includes are largely fixed by

- We do indeed have a lot of unnecessary includes around in llvm (or pretty much any other C++ project for that matter). - I want faster builds. - The only way to reliably fight this is indeed automatic tools. - Having the right amount of includes also has documentation value and ideally let's you understand the structure of your project. - However relying on transitive includes works contrary

On Tue, Nov 5, 2013 at 10:12 AM, <dag at cray.com> wrote: > Chandler Carruth <chandlerc at google.com> writes: > > So far, I'm not hearing any significant objections. > > > > I'm going to put the plan of record about this into the release notes, > > and I'll write up a blog post about it and do some other things which > > will likely make

Hi, I tweaked my scripts to avoid removing includes when it doesn't give any significant benefits, which made the patches significantly smaller. This time the patches should not try to remove includes of header files, which are transitively included from other included header files. The gains mostly remained the same (plus/minus noise), the tables are in the end of the email. I also included

On 8/8/19 2:03 PM, Hal Finkel wrote: Hi, First, as a high-level note, you posted a link to a Google doc, and at the end of the Google doc, you have a list of questions that you'd like answered. In the future, please put the questions directly in the email. For one thing, more people will read your email than will open your Google doc. Second, having the questions in the email should allow a

Starting from May-June, we at "Compiler Tree" would start porting clang compiler to use MLIR as middle end target. If someone has already started a similar effort we would love to collaborate with them. If someone would like to work with us, we are ready to form a group and collaborate. If there are sharing opportunities from Fortran side, we would like to consider the same. We are

2017-12-09 12:54 GMT-08:00 Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org>: > > > On Dec 8, 2017, at 5:01 PM, Mikhail Zolotukhin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > I tweaked my scripts to avoid removing includes when it doesn't give any > significant benefits, which made the patches significantly smaller. This >

> There is a fundamental problem with the way that ivdep is defined by Intel's current documentation, at least for C/C++. As you note in your Google doc, it essentially says that the optimizer may ignore loop-carried dependencies except for those dependencies it can definitely prove are present. These are not semantics that any other compiler can actually replicate, and is not equivalent to

> On Aug 26, 2015, at 8:21 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 26 August 2015 at 15:44, Tobias Grosser <tobias at grosser.es> wrote: >> What time-line do you have in mind for this fix? If you are in charge >> and can make this happen within a day, giving cmake + ninja a chance seems >> OK. > > It's not my bot.

Chandler Carruth <chandlerc at google.com> writes: > So far, I'm not hearing any significant objections. > > I'm going to put the plan of record about this into the release notes, > and I'll write up a blog post about it and do some other things which > will likely make enough noise to ensure we aren't missing people's > objections over the next few

On Thu, Oct 6, 2016 at 5:02 AM, Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Abe, > > My 2 cents: > I have been using the test-suite mainly in benchmarking mode as a convenient > way to track performance changes in top-of-trunk. > I've observed that some of the programs (IIRC, especially the ones in > SingleSource/Benchmarks/Polybench/) produce

On Tue, Jun 13, 2017 at 6:34 PM Peter Collingbourne via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On Wed, Jun 7, 2017 at 11:28 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Wed, Jun 7, 2017 at 8:06 PM, Sean Silva <chisophugis at gmail.com> wrote: >> >>> >>> >>> On Wed, Jun 7, 2017 at 4:31 PM, Peter Collingbourne

On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote: > My only hesitation with this is that this requires use of cherry-pick, > which is not idea. The way most git repositories work is to put > everything that should go into a release branch in the release branch > *first* and then merge the release branch to master, ensuring that > everything going out in a release will

I don’t think Apple disable assertion on the release build. I remember having clang and llvm crash because of assertion failure regularly at some point in the past. Nowadays, it is far more unusual to get a clang crash, so I can’t tell, but I doubt they change the configuration. > Le 20 nov. 2018 à 16:32, Jack Howarth via cfe-dev <cfe-dev at lists.llvm.org> a écrit : > > The

Hi, many of the bots on http://lab.llvm.org:8011/console don't do anything in their compile phase, even if they should. For example, these bots all don't do anything in their compile phase in any builds, even if they should: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/ http://lab.llvm.org:8011/builders/clang-ppc64be-linux

On Tue, May 31, 2016 at 4:27 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 31 May 2016 at 21:24, Aaron Ballman <aaron at aaronballman.com> wrote: >> Are we sure that github's svn integration works with common tools on >> Windows, like TortoiseSVN? > > That's a good question. Can you try them out and report back? >From my very simple testing,

I second the motion. All in favor? On Fri, Apr 1, 2016 at 10:57 AM, Renato Golin via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On 1 April 2016 at 18:50, Richard Smith via cfe-dev > <cfe-dev at lists.llvm.org> wrote: > > * The name has been used by a kickstarter project, causing incalculable > > confusion[0] > > Neal Stephenson has poetic license to do

On Apr 1, 2016 5:34 PM, "George Burgess IV via cfe-dev" < cfe-dev at lists.llvm.org> wrote: > > How are we casting our votes? Discordantly! > Will this be a standard yay-or-neigh format, or do people prefer an alternate method? > > On Fri, Apr 1, 2016 at 2:27 PM, Daniel Dilts via cfe-dev < cfe-dev at lists.llvm.org> wrote: >> >> I second the

On Mon, Oct 28, 2013 at 2:31 PM, Chris Lattner <clattner at apple.com> wrote: > Ok. If no-one has an objection, then putting it in the release notes (and > the announcement email!) makes sense. We can make the switch a few weeks > after the release if no one has strongly objected. So far, I'm not hearing any significant objections. I'm going to put the plan of record