[llvm-dev] [RFC] Removing Waymarking from Use.

Eric Christopher via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 14 10:32:21 PDT 2020


Yes please.

On Tue, Apr 14, 2020, 5:02 AM Tyker1 at outlook.com via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> a bit of time has passed and there to my knowledge still no strong
> arguments against removing it.
> is everyone OK to proceed with the removal ?
>
> Gauthier
> ------------------------------
> *From:* Chris Lattner <clattner at nondot.org>
> *Sent:* Saturday, April 4, 2020 7:40 PM
> *To:* Johannes Doerfert <johannesdoerfert at gmail.com>
> *Cc:* Ehud Katz <ehudkatz at gmail.com>; llvm-dev at lists.llvm.org <
> llvm-dev at lists.llvm.org>; Tyker1 at outlook.com <Tyker1 at outlook.com>
> *Subject:* Re: [llvm-dev] [RFC] Removing Waymarking from Use.
>
>
>
> On Apr 3, 2020, at 11:06 AM, Johannes Doerfert <johannesdoerfert at gmail.com>
> wrote:
>
>
>
> Is it worth it? I think it is. But I am not sure I see the whole picture -
> are there low-memory systems that need to run LLVM on?
>
> I am not sure what needs to be done to approve such a fundamental change;
> especially when we can't prove the Waymarking was needed at all.
>
> I guess if no-one brings forth arguments (= results) for keeping it and
>
> people continue to support replacing it, we will replace it. There should
>
> be a grace period in which people have the chance to do their benchmarking
>
> (basically what is happening), but I don't recall a problem being reported
> yet.
>
>
> I agree.  I’m not hearing strong arguments to retain it, so let's remove
> it.  Worst case, we can always reinstate it if there is a good reason
> discovered down the line.  Thank you!
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200414/65ec6ed3/attachment.html>


More information about the llvm-dev mailing list