search for: filcab

Hi, There are some warnings in the LLVM and clang code bases: ---------------------------- llvm[0]: Compiling RegAllocGreedy.cpp for Release+Asserts build /Users/filcab/dev/stuff/llvm/llvm/include/llvm/ADT/SmallVector.h: In member function ‘void<unnamed>::RAGreedy::calcLiveBlockInfo(llvm::LiveInterval&)’: /Users/filcab/dev/stuff/llvm/llvm/include/llvm/ADT/SmallVector.h:325: warning: ‘BC.llvm::SpillPlacement::BlockConstraint::Exit’ is used uninitialized i...

...reasonable: A record starts with a code. The code > can be encoded as a literal or be part of the abbreviation. > > There is probably not a lot of value in supporting a code embedded in the > first element of an array or blob. > > On 23 January 2015 at 16:47, Filipe Cabecinhas <filcab at gmail.com> wrote: > >> 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...

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

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

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

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

....com> > Subject: Re: [PATCH] D24569: [libcxx] Allow sanitizing libcxx with ASan+UBSan simultaneously > Date: 14 September 2016 at 19:01:29 GMT+2 > To: reviews+D24569+public+a5763c0a090df06f at reviews.llvm.org > Cc: kuba.brecka at gmail.com, eric at efcs.ca, compnerd at compnerd.org, filcab+llvm.phabricator at gmail.com, beanz at apple.com, zaks.anna at gmail.com, mgorny at gentoo.org > > >> On 2016-Sep-14, at 09:39, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> >> kubabrecka added inline comments. >> >> ================ >> Commen...

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

...s not seem enough to > handle generic cases. > > -----Original Message----- > From: Dinar Temirbulatov via llvm-dev [llvm-dev at lists.llvm.org] > Received: Dienstag, 12 Sep. 2017, 9:57 > To: llvm-dev at lists.llvm.org [llvm-dev at lists.llvm.org] > CC: Filipe Cabecinhas [me at filcab.net] > Subject: [llvm-dev] RFC phantom memory intrinsic > > 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 &g...

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

...>>> >>> -----Original Message----- >>> From: Dinar Temirbulatov via llvm-dev [llvm-dev at lists.llvm.org] >>> Received: Dienstag, 12 Sep. 2017, 9:57 >>> To: llvm-dev at lists.llvm.org [llvm-dev at lists.llvm.org] >>> CC: Filipe Cabecinhas [me at filcab.net] >>> Subject: [llvm-dev] RFC phantom memory intrinsic >>> >>> 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...

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

...allman,ab,adibiagio,adrian,ahatanak,ajbernal,akaylor,akirtzidis,alexfh,arnolds,arsenm,atrick,ayartsev,bwilson,carlokok,cdavis,chandlerc,chapuni,compnerd,ctopper,d0k,daenzer,dblaikie,ddunbar,delena,delesley,dgregor,dirty,djasper,dsanders,dvyukov,echristo,efriedma,enderby,enea,eugenis,faisalv,fangism,filcab,fjahanian,gribozavr,grosbach,hanm,hans,haoliu,hfinkel,jacksprat,jdennett,jholewinski,jimcownie,joerg,joey,jrose,jtsoftware,kevinqin,klimek,kremenek,kuba,labath,lattner,lhames,logan,lvoufo,majnemer,mgottesman,mkuper,mpopa,mren,mspencer,nadav,nicholas,nico,olesalscheider,papin_g,pcc,predmond,rafael,r...

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

...;>> -----Original Message----- >>>> From: Dinar Temirbulatov via llvm-dev [llvm-dev at lists.llvm.org] >>>> Received: Dienstag, 12 Sep. 2017, 9:57 >>>> To: llvm-dev at lists.llvm.org [llvm-dev at lists.llvm.org] >>>> CC: Filipe Cabecinhas [me at filcab.net] >>>> Subject: [llvm-dev] RFC phantom memory intrinsic >>>> >>>> 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 >>>> t...

...riginal Message----- >>>>> From: Dinar Temirbulatov via llvm-dev [llvm-dev at lists.llvm.org] >>>>> Received: Dienstag, 12 Sep. 2017, 9:57 >>>>> To: llvm-dev at lists.llvm.org [llvm-dev at lists.llvm.org] >>>>> CC: Filipe Cabecinhas [me at filcab.net] >>>>> Subject: [llvm-dev] RFC phantom memory intrinsic >>>>> >>>>> Hi, >>>>> For PR21780 solution, I plan to add a new functionality to restore >>>>> memory operations that was once deleted, in this particular case it i...

...---- >>>>>> From: Dinar Temirbulatov via llvm-dev [llvm-dev at lists.llvm.org] >>>>>> Received: Dienstag, 12 Sep. 2017, 9:57 >>>>>> To: llvm-dev at lists.llvm.org [llvm-dev at lists.llvm.org] >>>>>> CC: Filipe Cabecinhas [me at filcab.net] >>>>>> Subject: [llvm-dev] RFC phantom memory intrinsic >>>>>> >>>>>> Hi, >>>>>> For PR21780 solution, I plan to add a new functionality to restore >>>>>> memory operations that was once deleted, in this...