Displaying 4 results from an estimated 4 matches for "getfuncdata".
Did you mean:
getfontdata
2013 Jul 18
0
[LLVMdev] Proposal: function prefix data
...le below suggests that the frontend would then need to know magic to
put "raw" in the instruction stream. Have you considered having the feature
expose just the intent "store this data attached to the function, to be
accessed very quickly", and then have an intrinsic
("llvm.getfuncdata.i{8,16,32,64}"?) which extracts the data in a
target-dependent way? Forcing clients to embed deep
target-specific-machine-code knowledge in their frontends seems like a step
in the wrong direction for LLVM.
>
> This requirement could be relaxed when combined with my earlier symbol
>...
2013 Jul 18
2
[LLVMdev] Proposal: function prefix data
...at the frontend would then need to know magic to
> put "raw" in the instruction stream. Have you considered having the feature
> expose just the intent "store this data attached to the function, to be
> accessed very quickly", and then have an intrinsic
> ("llvm.getfuncdata.i{8,16,32,64}"?) which extracts the data in a
> target-dependent way?
The problem is that things like UBSan need to be able to understand
the instruction stream anyway (to a certain extent). In UBSan's case,
determining at runtime whether a function has prefix data depends on
a specif...
2013 Jul 18
6
[LLVMdev] Proposal: function prefix data
Hi,
I would like to propose that we introduce a mechanism in IR to allow
arbitrary data to be stashed before a function body. The purpose of
this would be to allow additional data about a function to be looked
up via a function pointer. Two use cases come to mind:
1) We'd like to be able to use UBSan to check that the type of the
function pointer of an indirect function call matches the
2013 Jul 18
0
[LLVMdev] Proposal: function prefix data
...n need to know magic to
> > put "raw" in the instruction stream. Have you considered having the
> feature
> > expose just the intent "store this data attached to the function, to be
> > accessed very quickly", and then have an intrinsic
> > ("llvm.getfuncdata.i{8,16,32,64}"?) which extracts the data in a
> > target-dependent way?
>
> The problem is that things like UBSan need to be able to understand
> the instruction stream anyway (to a certain extent). In UBSan's case,
> determining at runtime whether a function has prefix...