search for: ctsrd

...ted moving to the monorepo yet so while we haven't hit >> the issues in practice yet, we will. Preserving the history from the git >> mirrors would surely be beneficial. >> > > We are also in the same situation for our out-of-tree CHERI backend > (https://github.com/CTSRD-CHERI/llvm <https://github.com/CTSRD-CHERI/llvm> > https://github.com/CTSRD-CHERI/clang <https://github.com/CTSRD-CHERI/clang> > https://github.com/CTSRD-CHERI/lld <https://github.com/CTSRD-CHERI/lld>). I am aware there were some > attempts at converting our repos to a mo...

Hi, Thanks for starting this discussion Justin! On 10/31/18 5:22 PM, Justin Bogner via llvm-dev wrote: > Hi all, > > I've spent some time in the last couple of days trying to figure out how > to adopt the [LLVM git monorepo prototype] for an out of tree backend. > TLDR: I'm not convinced that this prototype is the right approach to > converting to the monorepo, and I

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

Hi David, sorry for sending you the mail two times, I forgot to send to the list the first time. On 2014-03-12 09:48, David Chisnall wrote: > I have some patches that automatically expand all memcpy and similar > if the operands are not in AS 0. I think this is probably not quite > the right approach though, and we should be asking the back end for > the function that does a memcpy

On Fri, 7 Sep 2018 at 17:48, Tim Northover <t.p.northover at gmail.com> wrote: > I looked at your diffs and you've only changed one of the functions to > return SDValue(), you need to change lowerFP_TO_SINT itself too. The > one with the store is just there as an optimization; if it doesn't > trigger (because of your diff) then lowerFP_TO_SINT will still create > a

On 20 Feb 2014, at 06:11, Ivan Godard <ivan at ootbcomp.com> wrote: > It's not just old mainframes, it's some of the newest architecture as well. > The Mill general-purpose architecture (http://ootbcomp.com) has non-integer > pointers and distinct pointer operations too. That LLVM loses pointerhood is > the biggest problem that we have identified while looking into using

...clones of the llvm and clang repos that were forked at some point in the past, have been periodically merged, and contain a load of commits on top of upstream would migrate to using this? > > Taking cheri as an example, it seems you have a repo for clang and one for llvm (https://github.com/CTSRD-CHERI/clang and https://github.com/CTSRD-CHERI/llvm) > > You can create the unified repo for cheri quite easily, it is roughly doing this: > > 1) checkout llvm, move everything to a llvm subdir, commit > 2) checkout clang, move everything to a clang subdir, commit > 3) merge cl...

...n the source and destination arguments are of the same size. We also have this problem for our architecture. We're currently doing the ptrtoint / inttoptr dance with lots of hacks and it's very ugly. Our tree is here, and I'd be happy to push any changes upstream: https://github.com/CTSRD-CHERI/llvm/ > Solution: > Remove the ability of bitcast to cast between pointers of different address spaces and replace with an instruction that handles this case explicitely. > > Proposed changes: > > * Add restriction to the verifier on the bitcast instruction making...

On 21 Jul 2016, at 16:11, James Y Knight <jyknight at google.com> wrote: > > I don't think this is a really hard problem though -- I can think of a few ways to help existing users that probably will work (although I'd want to try them first, to ensure it actually does work, of course). The two I'm thinking of are just doing "git diff" followed by "git apply

In our fork of LLVM we often need to reduce a crash testcase for a specific assertion. After writing lots of "only give me this specific assertion" scripts like the above I decided to write a script that automates all this for me: <https://github.com/CTSRD-CHERI/clang/blob/master/utils/creduce_crash_testcase.py>. (It's called creduce_crash_test.py but it will actually use bugpoint -compile-custom if it detects that it is not a clang frontend crash). If you point the script at a clang crash reproducer .sh file it will infer the assertion messag...

Well shoot, you beat me to it. :) I've been working on a similar tool but it's not ready yet. Looking forward to trying yours! -David James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes: > I'm about to post exactly this tool -- I've been testing it on the > CHERI forks of llvm/clang/lld (lots of history and merges and stuff

> Note that InstCombine is not the only place that tries to insert pointer-width GEPs in the optimization pipeline. I think that we’ve fixed all of them, but I can’t be entirely sure. I'm going to upload a patch, but I'm fixing only the places that are covered by our test system. I'll add you as a reviewer and you are welcome to help me with fixing them all. > We haven’t

I'm not sure if this helps, but here it is in case it does. I typically use bugpoint in a way as to keep the actual failure that I'm after. For example, with the test case you've pasted, I was looking for a specific assert. So I used bugpoint this way: $ cat reduceme.sh #!/bin/bash llc -filetype=obj $1 2>&1 | grep 'Cannot lower calls with arbitrary operand bundles'

...the only thing that is different is "align 16" vs "align 32". However, when checking the assembly output or linker addresses we often need something more complex. > > [2] A test case showing all the currently supported expressions can be found here: <https://github.com/CTSRD-CHERI/llvm/blob/master/test/FileCheck/expressions.txt> > > >> >> On Mon, 16 Jul 2018 at 18:39, <paul.robinson at sony.com> wrote: >> > >> > >> > >> > > -----Original Message----- >> > > From: llvm-dev [mailto:llvm-dev-bou...

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 >

...at is different is "align 16" vs "align 32". However, when checking the assembly output or linker addresses we often need something more complex. >> > >> > [2] A test case showing all the currently supported expressions can be found here: <https://github.com/CTSRD-CHERI/llvm/blob/master/test/FileCheck/expressions.txt> >> > >> > >> >> >> >> On Mon, 16 Jul 2018 at 18:39, <paul.robinson at sony.com> wrote: >> >> > >> >> > >> >> > >> >> > > -----Orig...

To be clear, I do not intend to add support for hex specifier in the current patch, I just want to make sure the syntax we choose is going to allow it later. My immediate use case is decimal integer and I intend to write the code so that it's easy to extend to more type of numeric variables and expressions later. This way we'll only add specifier that are actually required by actual

..."align 16" vs "align 32". However, when checking the assembly output or linker addresses we often need something more complex. >> >> > >> >> > [2] A test case showing all the currently supported expressions can be found here: <https://github.com/CTSRD-CHERI/llvm/blob/master/test/FileCheck/expressions.txt> >> >> > >> >> > >> >> >> >> >> >> On Mon, 16 Jul 2018 at 18:39, <paul.robinson at sony.com> wrote: >> >> >> > >> >> >> > >&g...

..."align 16" vs "align 32". However, when checking the assembly output or linker addresses we often need something more complex. >> >> > >> >> > [2] A test case showing all the currently supported expressions can be found here: <https://github.com/CTSRD-CHERI/llvm/blob/master/test/FileCheck/expressions.txt> >> >> > >> >> > >> >> >> >> >> >> On Mon, 16 Jul 2018 at 18:39, <paul.robinson at sony.com<mailto:paul.robinson at sony.com>> wrote: >> >> >> &gt...

...However, when checking the assembly output or linker addresses we often >> need something more complex. >> >> >> > >> >> >> > [2] A test case showing all the currently supported expressions >> can be found here: < >> https://github.com/CTSRD-CHERI/llvm/blob/master/test/FileCheck/expressions.txt >> > >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> On Mon, 16 Jul 2018 at 18:39, <paul.robinson at sony.com> wrote: >> >> >&g...