similar to: [LLVMdev] MCInsrAnalysis extansion

+Matthias > On Mar 2, 2018, at 6:42 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > >> Known limitations on X86 processors >> ----------------------------------- >> >> 1) Partial register updates versus full register updates. >> <snip> > > MachineOperand handles this. You just need to create the machine instrs. > >

Simplified vmx_platform.c by removing obsolete code and redundant vmread''s. Signed-Off-By: Leendert van Doorn <leendert@watson.ibm.com> diff -r 9cdfcecf4968 xen/arch/x86/vmx_platform.c --- a/xen/arch/x86/vmx_platform.c Wed Nov 2 16:29:32 2005 +++ b/xen/arch/x86/vmx_platform.c Wed Nov 2 21:12:02 2005 @@ -366,20 +366,15 @@ return DECODE_success; } -static int

Could you please expand a bit? Why are not the MCInstr and MachineInstr classes compatible? Is this not a long term goal, even? Could I make optimization passes in the MC layer with a disassembler as in a MachineFunction? Thanks, Jonas -----Original Message----- From: Eric Christopher [mailto:echristo at apple.com] Sent: Friday, February 17, 2012 8:20 PM To: Jonas Paulsson Cc: LLVMDEV

- we used the C4/C5 (first prefix) byte instead of the apparent ModR/M one as the second prefix byte - early decoding normalized vex.reg, thus corrupting it for the main consumer (copy_REX_VEX()), resulting in #UD on the two-operand instructions we emulate Also add respective test cases to the testing utility plus - fix get_fpu() (the fall-through order was inverted) - add cpu_has_avx2,

Hi Tim, Thank you for your response. I need that immediate value latter to concatenate to registers' names (which I am doing during assembly printing). Also just Updating some status for my questioin: I have continued with using *Defs* list. It allows me to keep Registers as an implicit operands of /*MachineInstr*/ and later during its lowering pass them to the /*MCInstr*/. Now seems I need

...Continued from the other email Removing the defs section We can potentially infer quite a lot of the defs section but it requires both a complicated ruleset and that tblgen spends processing time doing the inferencing. That processing time is potentially significant for large combiners and for that reason we need to be careful not to let inferencing become a burden on tblgen. My main worry

These utility functions will be used in the OCaml inspection code. --- daemon/daemon_utils_tests.ml | 15 +++++++ daemon/utils.ml | 100 +++++++++++++++++++++++++++++++++++++++++++ daemon/utils.mli | 12 ++++++ 3 files changed, 127 insertions(+) diff --git a/daemon/daemon_utils_tests.ml b/daemon/daemon_utils_tests.ml index 892509d89..b1f02de30 100644 ---

+Ahmed > On Mar 2, 2018, at 6:42 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > > There are a number of people on llvm-dev who can explain better than I how to decompile into MachineInstrs. I’m not totally opposed to checking in something that works with MCInstr, but this does run strongly contrary to the design of LLVM’s subtarget support. > > That would be

On Tue, May 24, 2016 at 3:50 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > Zooming into the command-line option bike-shed: > > > On 2016-May-24, at 15:41, Vedant Kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > At its core I don't think -fprofile-instr-generate *implies* FE-based > instrumentation. So, I'd like

On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jun 2, 2016 at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Thu, Jun 2, 2016 at 2:51 PM, Frédéric Riss <friss at apple.com> wrote: >> >>> >>> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at

Hi all, I get this error trying to build Wine on a Mac OS X 10.4.2. I've tried the prebuilt binaries, but couldn't get them to work and figured they're so old, I better try to build my own. I did apply the patches mentioned on the Darwine website. Below is the end of the make results (I've tried both the tools/wineinstaller and manually doing the build process with the same

> On Nov 29, 2018, at 02:02, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > On 27.11.18 19:01, Daniel Sanders wrote: >> ...Continued from the other email >> _Removing the defs section_ >> We can potentially infer quite a lot of the defs section but it requires both a complicated ruleset and that tblgen spends processing time doing the inferencing. That

Zooming into the command-line option bike-shed: > On 2016-May-24, at 15:41, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > At its core I don't think -fprofile-instr-generate *implies* FE-based instrumentation. So, I'd like to see the driver do this (on all platforms): > > * -fprofile-instr-generate: IR instrumentation > *

On Apr 26, 2008, at 17:41, Anders Johnsen wrote: > Hi Gordon, > > Thanks a lot for the feedback. I can see I've been way to > concentrated on how > llvm is build, then on this particular patch. I've done the changes > you have > suggested and it's now a lot nicer and cleaner! > > Please do say, if there is anything else. Nice. Just a few small

The 'systemfit' function in systemfit 0.7-3 CRAN package seems to have a problem with formulas that contain transformed (eg. log) variables. If I have my data in a data frame, apparently systemfit doesn't "pass" the information of where the variables should be taken to the transforming function. I'm not entirely sure if this is a bug or just a limitation, I was just

There is some misunderstanding about the intention of this flag. The purpose of the flag is not to turn on profile instrumentation (which already has -fprofile-instr-generate or -fprofile-generate for it), but to select which instrumentors to use for PGO (IR or FE). I prefer fewer flags too, but sharing flags for completely different purpose does not seem like the right thing to do. David On

On Sunday 27 April 2008 00:48:00 Gordon Henriksen wrote: > On Apr 26, 2008, at 17:41, Anders Johnsen wrote: > > Hi Gordon, > > > > Thanks a lot for the feedback. I can see I've been way to > > concentrated on how > > llvm is build, then on this particular patch. I've done the changes > > you have > > suggested and it's now a lot nicer and

Hi All, I've more or less finished updating the examples to the DAG style we were talking about. Hopefully I haven't forgotten anything, there was a lot to keep track of :-). Overall, I think there's a couple places where things get a a little awkward (mainly debug info) but things generally look good to me. A Simple Example def : GICombineRule<(defs reg:$D, reg:$S),

On Fri, Jun 24, 2016 at 1:44 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> Sounds fine to me, though I am not a fan of using unstable in the option. >> I think a more meaningful way (that capture the essence of the

> On Jun 2, 2016, at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > > This also means that if the consensus is that -fprofile-instr-generate should really change its meaning to mean IRPGO, I’m open to having this internal patch on our side. > > Yeah, it sounds like someone is going to have to keep a "private patch" to change the default. At that point