similar to: [LLVMdev] Fwd: Bitcode abbreviations for something that's not a record

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. > >

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 something similar? Is it desirable to have llvm-mc disassemble whole files? Or should I create another project for that?

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

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, I am creating n onlinecalendar sort of functionality for which the user input for events is taken. To make it user friendly, its left to the user to write the time down rather than selecting it from a datetime field in a form . The user can also specify a timezone. And while doing so its obvious that most inputs will be an abbreviation. My question is - is there a way to convert

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

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

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

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

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],

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

<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

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 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

Hi there, Here is my situation: > User NEWBIE!!!!! > version _ platform i386-pc-mingw32 arch x86 os Win32 system x86, Win32 status major 1 minor 2.2 year 2001 month 02 day 26 language R I wonder why. Given this data

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

On 09/26/2017 08:31 AM, Dinar Temirbulatov wrote: > 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

Hi everyone, In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null address) when the symbol is not found : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } return

Hi, LLVM made a change a few months ago and starting erroring out when a float is returned in x64 and SSE is disabled. This makes sense, really, since it's specified by the ABI that the return value must be put in a register you were told to disable, but it's breaking soft floats in Rust on x64. It seems there are two options: LLVM could break the ABI spec and have working soft floats on