similar to: [fdo] Code of Conduct questions

On Thu, Feb 7, 2019, 09:21 Simon Moll <moll at cs.uni-saarland.de> wrote: > > On 2/7/19 6:08 PM, David Greene wrote: > > Jacob Lifshay <programmerjake at gmail.com> writes: > > > >> So it would be handy for the vector length on evl intrinsics to be in > >> units of the mask length so we don't have to pattern match a division > >> in the

On Fri, Feb 1, 2019 at 1:19 AM Bruce Hoult <brucehoult at sifive.com> wrote: > On Thu, Jan 31, 2019 at 11:53 PM Luke Kenneth Casson Leighton via > llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > --- > > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > > On Thu, Jan 31, 2019 at 10:22 PM Jacob Lifshay

+cfe-dev at lists.llvm.org On Thu, Jan 10, 2019 at 2:16 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > Stash a lookup table from integers to strings in Context and dynamically allocate integers for new strings. You can then keep integers in most of the code, writing/displaying strings for the integers with an entry in the table when writing to files or displaying. > >

On Thu, Jan 30, 2020, 10:22 Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I want to restart this discussion. There seemed to be support for this, > but we got held up trying to decide on the appropriate set of tags to > use to classify issues. > > I propose that we move forward with this proposal and disable creation of > new bugs in

On Tuesday, October 1, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote: > On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I've posted two patches on Phabricator to add support for VScale in LLVM. Excellent! > > > > A brief recap on `vscale`: > > The scalable vector type in

Jacob Lifshay <programmerjake at gmail.com> writes: > So it would be handy for the vector length on evl intrinsics to be in > units of the mask length so we don't have to pattern match a division > in the backend. We could have 2 variants of the vector length > argument, one in terms of the data vector and one in terms of the mask > vector. we could legalize the mask

On Fri, 30 Nov 2018, Kees Cook wrote: >On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen ><jarkko.sakkinen at linux.intel.com> wrote: >> >> In order to comply with the CoC, replace **** with a hug. I hope this is some kind of joke. How would anyone get offended by reading technical comments? This is all beyond me... Thanks, Davidlohr

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Jan 31, 2019 at 10:22 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > We're in-progress designing a RISC-V extension (http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html) that would have variable-length vectors of short vectors (1 to 4): > <VL x <4 x

I've posted two patches on Phabricator to add support for VScale in LLVM. A brief recap on `vscale`: The scalable vector type in LLVM IR is defined as `<vscale x n x m>`, to create types such as `<vscale x 16 x i8>` for a scalable vector with at least 16 bytes. In the definition of the scalable type, `vscale` is specified as a positive constant of type integer that will only be

On Mon, 4 Feb 2019 at 22:04, Simon Moll <moll at cs.uni-saarland.de> wrote: > On 2/4/19 9:18 PM, Robin Kruppe wrote: > > > > On Mon, 4 Feb 2019 at 18:15, David Greene via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Simon Moll <moll at cs.uni-saarland.de> writes: >> >> > You are referring to the sub-vector sizes, if i am

Hi, Lang As a starter using LLVM JIT to improve OLAP execution engine performance, I'm very glad to hear that. I can't find some useful document help me get start to use the new ORC JIT API quickly. Only can find some examples how to use it, but don't know the internal from low level, and very blurred to design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT more

Hello, We would like to propose a way for improving the diagnostics for address_space by being able to pass strings as an argument to it instead of just an integer. This was initially proposed before (http://lists.llvm.org/pipermail/cfe-dev/2018-August/058702.html) but did not focus on it at the time. Reasoning: Clang's __attribute__((address_space(...))) feature uses an arbitrary integer as

Greetings everyone, On behalf of the board of the LLVM Foundation, I’d like to start the process of introducing a formal code of conduct for the community. For a long time, various members of the community have been enforcing basic reasonable and respectful behavior, but to an outsider this may not be obvious. A public code of conduct advertises the behavior we expect of community members and

Dear Colleagues/Developers/R enthusiasts, Would it be possible to develop a code of conduct (CoC) document for R lists, CRAN submissions that all developers/maintainers to follow? This may help all of us to better communicate and move forward together. There is a similar effort from Python community, here are the links: * https://mail.python.org/pipermail/scipy-dev/2017-August/022044.html *

Hi, There is now an RFC for a roadmap to native vector predication support in LLVM and a prototype implementation:   https://reviews.llvm.org/D57504 The prototype demonstrates: -  Predicated vector intrinsics with an explicit mask and vector length parameter on IR level. -  First-class predicated SDNodes on ISel level. Mask and vector length are value operands. -  An incremental strategy

On 5/5/2016 4:19 PM, Tanya Lattner via llvm-dev wrote: > Having a code of conduct like this is just as bad as having no code of conduct at all. It trivializes the importance of a code of conduct and its pretty much impossible to enforce. Code of conduct should reflect the community standards, not define them. These standards come from the minds of the members of the community. A CoC that

+1 for this TL;DR suggestion - you can guarantee most people would read < 7 short bullet points. Cheers, -Neil. On 06/05/16 15:53, Arnaud Allard de Grandmaison via llvm-dev wrote: > For what it's worth, I think this is an improved version of the CoC, > and I'm OK with it. Thanks to Chandler and all those who have been > working on it. > > It's not perfect ---

https://bugzilla.mindrot.org/show_bug.cgi?id=3534 Bug ID: 3534 Summary: probable underflow calculating display width of file name Product: Portable OpenSSH Version: -current Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: scp

Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the

Hi, Fixing http://llvm.org/PR39427 in the release_70 branch, will change the ABI of a clang built libLLVM-7.so so that it is no longer compatible with the 7.0.0 release. libLLVM-7.so built by gcc will not be affected by this fix. Changing the ABI is something we aren't supposed to do in stable releases, but this fixes an ABI difference between clang and gcc built libLLVM-7.so that is