search for: simhon

...ommon will be the data structure inside the immutable pass. Am I right? You can see the phabricator review that I uploaded yesterday here: https://reviews.llvm.org/D28566 Thanks, Oren From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Thursday, January 12, 2017 12:05 To: Ben Simhon, Oren <oren.ben.simhon at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC: Dynamically Allocated "Callee Saved Registers" Lists On Jan 12, 2017, at 1:03 AM, Ben Simhon, Oren <oren.ben.simhon at intel.com<mailto:oren.ben.simhon at intel.com>> wrote...

...ent type of register masks. I don’t see how we can change the mechanism to make IPRA and my updated regmask mutual exclusive. I hope it clarifies what I am trying to say. Thanks, Oren From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Thursday, January 12, 2017 09:52 To: Ben Simhon, Oren <oren.ben.simhon at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC: Dynamically Allocated "Callee Saved Registers" Lists Hi Ben, On Jan 11, 2017, at 11:26 PM, Ben Simhon, Oren <oren.ben.simhon at intel.com<mailto:oren.ben.simhon at intel.com>...

...So how can they share the same mechanism? Regarding immutable pass, I am not familiar with immutable passes that hold correctness information (can you share an example?). Thanks, Oren From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Wednesday, January 11, 2017 20:22 To: Ben Simhon, Oren <oren.ben.simhon at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC: Dynamically Allocated "Callee Saved Registers" Lists On Jan 11, 2017, at 7:06 AM, Ben Simhon, Oren <oren.ben.simhon at intel.com<mailto:oren.ben.simhon at intel.com>> wrote...

...inside the Machine Function but as mentioned by #1 it is not recommended. Thus I believe that using my current suggestion is more suitable for the issue I am resolving. Best Regards, Oren From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Monday, January 09, 2017 18:38 To: Ben Simhon, Oren <oren.ben.simhon at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC: Dynamically Allocated "Callee Saved Registers" Lists On Jan 9, 2017, at 1:09 AM, Ben Simhon, Oren via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>&g...

Hi, I want to add Target Specific MachineFunctionPass so that it will run during Link Time Optimization. The pass is currently running in non-LTO compilation (added in addPreEmitPass). What do I need to do in order to run my pass also during LTO? Thanks, Oren --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may

Hi All, The Register Calling Convention (RegCall) was introduced by Intel to optimize parameter transfer on function call. This calling convention ensures that as many values as possible are passed or returned in registers. To use RegCall, place the keyword before a function declaration. For example: __regcall int foo (int i, int j); // Windows OS __attribute__((regcall)) foo (int I, int j); //

Dynamically Allocated "Callee Saved Registers" Lists Each Calling convention (CC) defines a static list of registers that should be preserved by a callee function. All other registers should be saved by the caller. Some CCs use additional condition: If the register is used for passing/returning arguments - the caller needs to save it - even if it is part of the Callee Saved Registers

Adding Support For Vectorcall Calling Convention ===================================================== Vectorcall Calling Convention for x64 ---------------------------------------------------- The __vectorcall calling convention specifies that arguments to functions are to be passed in registers, when possible. __vectorcall uses more registers for arguments than __fastcall or the default x64

I'd think we shouldn't do anything even for printing out a warning unless doing it is proved to be useful. On Wed, Mar 21, 2018 at 1:04 AM George Rimar <grimar at accesssoftek.com> wrote: > >I think we should wait until there is someone wanting to use these > features with lld. > > > >Cheers, > >Rafael > > Ok. Should we give an error when

...evmtg/2018-04/talks.html#Talk_17). It was mentioned that some support is already implemented in LLVM. I did not have chance to look close on it though. Whole feature requires linker side support, current status: bfd support this, gold - still does not. I would love to see some comments from O. Simhon? in this thread probably. Best regards, George | Developer | Access Softek, Inc ________________________________ От: Rui Ueyama <ruiu at google.com> Отправлено: 23 марта 2018 г. 0:58 Кому: George Rimar Копия: rafael at espindo.la; llvm-dev Тема: Re: [LLD/ELF] - Should we implement .note.gnu...

>I think we should wait until there is someone wanting to use these features with lld. > >Cheers, >Rafael Ok. Should we give an error when .note.gnu.property section is in the object?? ?Best regards, George | Developer | Access Softek, Inc -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi All, Jump Oriented Programming attacks rely on tampering addresses used by indirect call / jmp, e.g. redirect control-flow to non-programmer intended bytes in binary. A new target independent command line option -fcf-protection=<branch/return/full/none> instruments control flow protection schemes to handle such attacks. X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow