similar to: [LLVMdev] Extending llvm-mc to whole executables/libraries

On Wed, Jan 19, 2011 at 6:00 PM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Hi, > I want to extend llvm-mc to make it disassemble whole files, instead of > sequences of bytes. > Most of the work to read from a Mach-O file is already done by lldb, but > that is outside llvm's repository and not useful to llvm-mc (as far as I > know). > Is anyone working on

Ok, I'll submit a patch to turn that into a report_fatal_error saying you can't start an abbrev with an array or blob. Thanks, Filipe F On Fri, Jan 23, 2015 at 2:12 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > The restriction looks reasonable: A record starts with a code. The code > can be encoded as a literal or be part of the abbreviation. > >

On Sun, Feb 7, 2010 at 12:30 AM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Hi, > > Try these scripts to build llvm and llvm-gcc. It's the ones I use and I > managed to get them to work when I saw another build script using those > CFLAGS. > > They compile llvm and stuff using only x86_64, but you can then generate > code for i386 (just use a different

On Wed, Apr 20, 2016 at 1:42 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 20 April 2016 at 13:18, Yury Gribov <y.gribov at samsung.com> wrote: >> Not when dead store happens in an external DSO where compiler can't detect >> it (same applies for single references). > > Do you mean the ones between the DSO and the instrumented code? >

Hi, On 5 Jun, 2008, at 19:12, Mike Stump wrote: > The option is no longer needed and hasn't been for quite some time. > Just remove it. So, even in gcc 4.0.1 (the current for Mac OS X), it doesn't do anything? Thanks for the reply, - Filipe Cabecinhas

Hi all! Fuzzing llvm's bitcode reader, I found a problem where the reader assumes that the first field in an abbreviation will not be an array or a blob (and asserts otherwise). I don't know if this is expected (but not documented) or not. The documentation, to me, reads like it doesn't disallow it, but we might be assuming all abreviations start with a full record, which would make

On Tue, Apr 19, 2016 at 1:18 PM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Thanks for proposing this. It seems like it might be an interesting > tool for us too. But this proposal seems a bit hand-wavy, and I think > it's missing some crucial info before we start heading this way. > > At least for the tools you are currently starting to implement, it > would be

Hi Michael, >Interesting approach but how do you handle more complex offsets, e.g., when the pointer is part of an aggregate? Only one offset does not seem enough to handle generic cases. Yes, correct, this a little bit changed example is not working. #include <x86intrin.h> __m256d vsht_d4_fold(const double* ptr, unsigned long long i) { __m256d foo = (__m256d){ ptr[i], ptr[i+1],

Indeed. But the problem here is that Dinar is trying to keep information after a load/store is removed by instcombine For example: v4sf v = {p[0], p[1], p[2], p[3]}; v4sf v2 = shuffle(v, 0, 0, 2, 2); Some pass comes in and removes the p[3] and p[1]. Now you have smaller code, but lost the ability to use a vector load for all those values + shuffle. The code got scalarized because we lost the

Hi, LLVM-gcc can't recognize this option, don't know why, because the gcc in Mac OS X (quite old, compared to 4.2) can recognize it. - Filipe Cabecinhas

<dag at cray.com> writes: >> - API instability is the exact same problem as code review latency -- >> the API is no more stable, you're just deferring work. > > Yes, none of these things go away. That's not the point. The point is > that with a separate branch one can *schedule* them. Code review on > llvm-commits is painful not because of the actual

On Tuesday, June 26, 2012 at 5:43 PM, dag at cray.com wrote: > <dag at cray.com (mailto:dag at cray.com)> writes: > > > > - API instability is the exact same problem as code review latency -- > > > the API is no more stable, you're just deferring work. > > > > > > > > Yes, none of these things go away. That's not the point. The

Hi Michael, >I have a case where InstCombine removes a store and your approach would be >valuable for me if the entire access to an aggregate could be restored. Yes, no problem and we could add the aggregate pointer to this new intrinsic and in my particular case I should ignore it, but I am looking now at "speculation_marker" metadata and I am still not sure how to implement it

Hi, For PR21780 solution, I plan to add a new functionality to restore memory operations that was once deleted, in this particular case it is the load operations that were deleted by InstCombine, please note that once the load was removed there is no way to restore it back and that prevents us from vectorizing the shuffle operation. There are probably more similar issues where this approach could

+1 On Wed, May 4, 2016 at 3:10 AM, Filipe Cabecinhas via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On Wed, May 4, 2016 at 9:35 AM, Ronan KERYELL via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >>>>>> On Tue, 3 May 2016 16:36:01 -0400, Rafael Espíndola via llvm-dev < > llvm-dev at lists.llvm.org> said: > > > >

On 09/13/2017 04:46 PM, Dinar Temirbulatov via llvm-dev wrote: > Hi Michael, >> I have a case where InstCombine removes a store and your approach would be >> valuable for me if the entire access to an aggregate could be restored. > Yes, no problem and we could add the aggregate pointer to this new > intrinsic and in my particular case I should ignore it, but I am > looking

Hi Hal, >Are you primarily concerned with being able to widen loads later in the pipeline? Could we attached metadata to the remaining loads indicating that it would be legal to widen them? no, I don't have any concerns about intrinsic way of implementation, and intrinsic way looks safer for me since we somehow detach our information about memory from that actual load instruction. I updated

On Jun 5, 2008, at 3:15 AM, Filipe Cabecinhas wrote: > LLVM-gcc can't recognize this option, don't know why, because the gcc > in Mac OS X (quite old, compared to 4.2) can recognize it. The option is no longer needed and hasn't been for quite some time. Just remove it.

Filipe Cabecinhas wrote: > Just a thought... How are you going to port llvm so it doesn't use libc? > Valgrind uses the same resources as the running program, so it can't use > the system libc's malloc nor any other functions so it doesn't get > "confused". I think you could to put LLVM into a different process. >> I think I'm the one who put

The usual advice I provide people is "see what Clang does with an equivalent C construct" On Wed, May 4, 2016 at 12:18 PM, Stanislav Manilov < stanislav.manilov at gmail.com> wrote: > Hi, > > There is another benefit to keeping the CppBackend: it's great for > learning how to use the IR and the C++ API in particular, as can be seen > from this SO Q&A: >