search for: ephe

On Fri, Nov 15, 2019 at 10:58 AM Fāng-ruì Sòng <maskray at google.com> wrote: > Since you are going to rewrite the mlir history anyway, you can > probably delete accidentally checked in large files if any. > Good point, I checked and this is the largest file in the history of the repo as far as I can tell:

> On Jul 22, 2016, at 7:28 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Jul 22, 2016, at 12:31 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: >> >> On 22 Jul 2016, at 07:14, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Just tried to set it up there:

On 22 Jul 2016, at 07:14, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Just tried to set it up there: https://github.com/joker-eph/llvm-unified > (git log —follow is working fine with this setup). > > While it preserves the history fine (I.e. the hashes are identical to the current git), it has a drawback: there isn’t anymore a common ancestor for the

I mean, we could change it twice? There are about a hundred scripts out there for doing it. -eric On Fri, Jun 19, 2020 at 11:40 AM Keane, Erich <erich.keane at intel.com> wrote: > Do we have any ability to reach out to github (at least?) to see what they > are going to do? I’d very much like to avoid being the odd-project-out > here. > > > > > > > >

Seems like everything is operational now! Let me know if anything seems off. In particular the email configuration took me a while to figure out, it isn't clear to me how Phab was possibly receiving email before? I upgraded the VM without changing the Phabricator version, I'll likely look into upgrading Phabricator itself next weekend. -- Mehdi On Sun, Jul 5, 2020 at 9:02 PM Mehdi

To be clear: I’m concerned about the amount of our infrastructure (as well as downstream infrastructure, this would be actually pretty painful for both of my downstreams) that the community would have break/need fixing as a part of that. So I want this to happen ONCE. I think it is well motivated now, but switching from ‘default’ to ‘main’ when that becomes the ‘standard’ one seems way less

We tested on 3.4.2 and 3.5.1. Later versions are slightly problematic to test since they don't compile with VS2010. Do you happen to know if it's fixed in one of the released versions, or if there is a workaround (chkstk?) or a bug report online? Thanks! Eph On 30.06.2015 12:58, Nicholas Chapman wrote: > It's a known issue. I believe it's fixed in trunk however. >

Are we agreeing on this is what we should do? If so, I will prepare a patch. Steven > On Feb 8, 2018, at 11:07 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2018-02-08 10:44 GMT-08:00 Steven Wu <stevenwu at apple.com <mailto:stevenwu at apple.com>>: > > >> On Feb 8, 2018, at 10:28 AM, Mehdi AMINI <joker.eph at gmail.com

That's a good point, we should definitely be respectful of the build bot owners time, that said I think it's the coordination that takes the time rather than the change :) On Fri, Jun 19, 2020 at 11:48 AM Keane, Erich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > My understanding is the biggest concern about the name change is the > ‘cost’ associated with needing to

The one that doesn’t require global analysis is commit in r324757. The global analysis will require adding a field into GlobalSummary. Let me do some research. The implementation should not be hard but I don’t want to break bitcode compatibility if that applies to the summary. Steven > On Feb 9, 2018, at 9:33 AM, Teresa Johnson <tejohnson at google.com> wrote: > > SGTM. I would

Add Rafael here. Because he basically ask me the same question in my commit. I wonder why clang choose to do unnamed_addr instead of just do visibility hidden. If linkonce_odr + unnamed_addr is just hidden, is the only difference linkonce_odr + unnamed_addr not in the symbol table? Steven > On Feb 9, 2018, at 10:50 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > I wonder

SGTM. I would do as 2 separate patches, the local per-module case, then the case that requires linker/global analysis. Thanks, Teresa On Fri, Feb 9, 2018 at 9:20 AM, Steven Wu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Are we agreeing on this is what we should do? If so, I will prepare a > patch. > > Steven > > > On Feb 8, 2018, at 11:07 AM, Mehdi AMINI

2018-02-08 10:44 GMT-08:00 Steven Wu <stevenwu at apple.com>: > > > On Feb 8, 2018, at 10:28 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2018-02-08 9:33 GMT-08:00 Steven Wu <stevenwu at apple.com>: > >> >> >> On Feb 7, 2018, at 4:03 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: >> >> >> >>

Hi All, we have an issue with our LLVM-based JIT compiler - executing the compiled code corrupts memory (and subsequently crashes) if we alloca more than 4k of variables (more than 511 8-byte ints). The same code works on Windows 7 (32 and 64 bit), Linux, MacOS. We compile LLVM and our program with Microsoft's Visual Studio 2010. Both debug and release builds are affected. The variables

I disagree with your timing concerns. Changing is still straightforward and I'd like to see this done within 1-2 weeks. Thanks. -eric On Fri, Jun 19, 2020 at 12:22 PM Chris Tetreault <ctetreau at quicinc.com> wrote: > +1 to waiting until git and/or github decide on a new name for the default > branch. I think there is a compelling reason to change the name of the > default

I wonder whether we could change the frontend to always give hidden visibility to globals which are linkonce_odr unnamed_addr. That way, the mechanism would just work in ELF as well and would not require LTO. Peter On Fri, Feb 9, 2018 at 10:46 AM, Steven Wu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The one that doesn’t require global analysis is commit in r324757. > >

There's really no guarantee that things will shake out the same in near term between the projects. -eric On Fri, Jun 19, 2020 at 11:31 AM Keane, Erich <erich.keane at intel.com> wrote: > I’m a bit mixed on this. While yes, we should change this as soon as is > practical, it would be a shame to pick something sufficiently different > from the rest of the world, as that would

> On Aug 9, 2016, at 1:38 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Aug 9, 2016, at 11:27 AM, Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >>> (2) If I’m stuck using git-svn I kinda feel like there is no real point in changing anything. >> >>

On Fri, Feb 16, 2018 at 8:26 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 2018-02-13 17:46 GMT-08:00 Mehdi AMINI <joker.eph at gmail.com>: > >> >> >> 2018-02-13 13:29 GMT-08:00 Quentin Colombet <qcolombet at apple.com>: >> >>> Hi Mehdi, >>> >>> >>> On Feb 13, 2018, at 12:34 PM, Mehdi AMINI

2018-02-13 17:46 GMT-08:00 Mehdi AMINI <joker.eph at gmail.com>: > > > 2018-02-13 13:29 GMT-08:00 Quentin Colombet <qcolombet at apple.com>: > >> Hi Mehdi, >> >> >> On Feb 13, 2018, at 12:34 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: >> >> >> >> 2018-02-08 17:34 GMT-08:00 Quentin Colombet via llvm-dev < >>