search for: montoro

...can't do the required commoning. So the general approach taken in https://reviews.llvm.org/D62802 seems to be the only technically viable path forward, though it would still be good to get an outside look at the concrete details. Thanks, Nicolai On Mon, Jun 3, 2019 at 10:35 AM Nicolai Hähnle-Montoro <nhaehnle at gmail.com> wrote: > > Hi all, > > re-upping and renaming this thread to get some attention, as we'd like > some feedback on a change that affects the future design direction. > > The concrete problem: We would like to mark the LCSSA pass as > preservin...

On Tue, Oct 29, 2019 at 11:57 AM Savonichev, Andrew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > These are good points. I think the first question should be: Do we know > > of any active users of this attribute right now? If not, deprecation > > seems like something we could do, e.g., through a warning in clang and > > in the middle-end to ensure other

Hello, I'm trying to run checks with EXPENSIVE_CHECKS enabled, but it crashes when generating some intrinsics file with TableGen. > cd /home/luke/Source/llvm-project/build && /home/luke/Source/llvm- > project/build/bin/llvm-tblgen -gen-intrinsic-impl -I /home/luke/Source/llvm- > project/llvm/include/llvm/IR -I /home/luke/Source/llvm-project/llvm/include >

Some background: We have an issue with in loop values being correctly marked uniform but the out of loop uses can be non-uniform. Currently the out of loop users are not marked as divergent because the in loop value is uniform inside the loop. We have gotten around this problem for the moment by applying LCSSA which inserts a PHI in the loop exit for the in loop uniform value that allows the

Hi, We are still on track to retire SVN and complete the transition to GitHub by Oct 21, 2019 (This year's US Dev Meeting). Even though this 3+ months away, it is very important that you begin to migrate your workflows to GitHub as soon as possible. For developers, this means using the git-llvm script to commit changes and for CI systems or other read-only use cases can begin fetching code

Hi all, At some time in the near future we would like to allow for Rust to use the new PM. As I understand it, Rust uses LLVM through the stable LLVM C API, which currently only provides an interface to the legacy PM. We wanted to ask what people think about how we should go about exposing the new PM through this API. We can think of 3 possibilities for now: 1) Just replace the API to expose the

> What do you mean exactly by "behave differently on the other side of the cast”? Do you have a concrete example? I was hesitant to say only in that it is probably an "abuse of mechanics" and definitely playing with fire, _however_ the target I'm working on has extensive bit operations for a subset of memory, including atomic test-and-set, etc. It's convenient to be

Hi, I’ve been thinking about what the strategy to use for boolean values in GlobalISel. There are a few semantic and mechanical issues I’ve encountered. For background, on AMDGPU, there are two kinds of bool/s1 values. Contextually, a real boolean value will either be a 1-bit scalar condition (in a non-allocatable physical condition register, which will need to be copied to an allocatable class