search for: liad

...1 BB#1 ...some opcodes... I'd like to put a place holder instead of the BB#1 in the mov opcode, and create a symbol named "BB#1" that points to that opcode, so during link time I can replace that placeholder with the actual address of BB#1. Again thank you for your time and answer, Liad. On Thu, Dec 14, 2017 at 9:03 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > The .symtab has symbols; you could define a label for the instruction, and > store something in the symbol table entry for the label. This kind of > thing would be done in the MC layer. > >...

Hi Liad, I'm not an expert in MC, but what you describe doesn't sound any different from how you would handle a branch instruction. Create an MCSymbol that represents the address of the target instruction; use that symbol as an operand in the referencing instruction; emit the symbol as a label jus...

...en all those workarounds wouldn't be needed, this example is only one of a few I can think of for expanding the CallingConvention tablegen capabilities regarding this issue. Thanks for the answer. On Wed, Aug 8, 2018 at 4:21 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Liad, > > On Wed, 8 Aug 2018 at 13:28, Liad Mordekoviz via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Did anyone else come by such requirement? is there any other way anyone > could recommend handling such requirement? > > Apple's calling convention on iOS does...

...on a new backend. I am trying to add information to a specific instruction using the .symtab in the ELF format. I've been searching through the LLVM source code trying to find a way to do such a thing. Can anyone help me with some directions or point me to some documents in the matter. Thanks, Liad. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171214/efdb64b4/attachment.html>

.../CodeGen/CallingConvLower.cpp#L138 In line 144 the Fn is called, the Outs[i] contains the information required for such thing because it contains the IsFixed flag. Did anyone else come by such requirement? is there any other way anyone could recommend handling such requirement? Thanks in advance, Liad. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180808/c88648cb/attachment.html>

...y the same): http://llvm.org/svn/llvm-project/ llvm-project -> llvm (llvm repo) -> clang (clang repo) -> lld (lld repo) etc. It seems like the CMake files support both options. So we would like to know which of them should be supported for the foreseeable future. Thanks in advance, Liad. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180219/3666a0e3/attachment.html>

...etLowering::LowerCall function. Before going said path, I was wondering if there is some way to split the BB before the SelectionDAG is generated, this way the call instruction would be last in the SelectionDAG would be last and won't get deleted during the combining stage. Thanks in advance, Liad. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180121/faec1422/attachment.html>

...rward, things are likely to move around. The second layout is more flexible because it doesn't put any repo inside another repo, so I would recommend adopting it. At the very least, using it will put you in a good position to adapt to any future layout changes. On Mon, Feb 19, 2018 at 1:36 AM Liad Mordekoviz via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hey all, > There seems to be two conventions for git repo directory layout. > The official docs suggest the following tree. > http://llvm.org/docs/GettingStarted.html#git-mirror > > llvm (llvm repo) > ->...