FFI call attributes #151

New Issue

pca006132 · 2021-12-23T20:59:15+08:00

pca006132 commented

2021-12-23 20:59:15 +08:00

We should add these attributes correctly to those extern functions.

https://github.com/m-labs/artiq/pull/1778/files

We should add these attributes correctly to those extern functions. https://github.com/m-labs/artiq/pull/1778/files

pca006132 commented

2021-12-23 21:02:28 +08:00

Attributes ID can be obtained from string using get_named_enum_kind_id

Attributes ID can be obtained from string using [`get_named_enum_kind_id`](https://thedan64.github.io/inkwell/inkwell/attributes/struct.Attribute.html#method.get_named_enum_kind_id)

sb10q added the

high-priority

label 2022-01-03 13:27:31 +08:00

sb10q added this to the Prealpha milestone 2022-01-03 13:27:33 +08:00

pca006132 commented

2022-01-03 14:28:51 +08:00

M-Labs/artiq-zynq#76

Considering this, should we keep the byval attribute? It seems that the backend can do some optimization with byval attribute (pass aggregate types in register rather than in stack memory), but how much does this affect performane? If the performance implication is not big, should we simplify this by removing the attribute?

https://git.m-labs.hk/M-Labs/artiq-zynq/issues/76 Considering this, should we keep the byval attribute? It seems that the backend can do some optimization with byval attribute (pass aggregate types in register rather than in stack memory), but how much does this affect performane? If the performance implication is not big, should we simplify this by removing the attribute?

sb10q commented

2022-01-03 14:38:54 +08:00

I don't understand the connection between the attributes and #76. Are you saying that not using byval fixes the discrepancy in #76?

I don't understand the connection between the attributes and #76. Are you saying that not using ``byval`` fixes the discrepancy in #76?

pca006132 commented

2022-01-03 15:34:12 +08:00

I don't understand the connection between the attributes and #76. Are you saying that not using byval fixes the discrepancy in #76?

It causes the discrepancy in zynq, i.e. both functions take a slice pointer, but one is using &CSlice and one is CSlice. With byval, the backend may not emit a point to struct but pass the struct content in register instead.

The discrepancy between different targets is caused by the target ABI, more specifically how they handle function parameters of aggregate type. Some targets will pass the aggregate value by pointer and some will pass in register if there are available registers (for performance reason). This can probably be fixed by using pointers to struct instead of passing structs directly, which should always be lowered as a pointer argument (if my understanding is correct).

Note: Adding the attribute is easy, I'm just a bit worried about the discrepancy.

> I don't understand the connection between the attributes and #76. Are you saying that not using ``byval`` fixes the discrepancy in #76? It causes the discrepancy in zynq, i.e. both functions take a slice pointer, but one is using &CSlice and one is CSlice. With byval, the backend may not emit a point to struct but pass the struct content in register instead. The discrepancy between different targets is caused by the target ABI, more specifically how they handle function parameters of aggregate type. Some targets will pass the aggregate value by pointer and some will pass in register if there are available registers (for performance reason). This can probably be fixed by using pointers to struct instead of passing structs directly, which should always be lowered as a pointer argument (if my understanding is correct). Note: Adding the attribute is easy, I'm just a bit worried about the discrepancy.

pca006132 commented

2022-01-03 16:13:10 +08:00

And another thing we may want to have a look at is fastcc. Do we want to make the code faster by making calls to private functions fastcc? How much improvement would we get from this?

(wandering in the LLVM language reference now... just some random thoughts that I want to note down)

And another thing we may want to have a look at is fastcc. Do we want to make the code faster by making calls to private functions fastcc? How much improvement would we get from this? (wandering in the LLVM language reference now... just some random thoughts that I want to note down)

pca006132 was assigned by sb10q

2022-03-02 16:59:24 +08:00

pca006132 referenced a pull request that will close this issue

2022-03-09 22:13:49 +08:00

nac3core: impl call attributes #217

sb10q closed this issue

2022-03-09 22:25:29 +08:00

Sign in to join this conversation.