Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Name resolution #16

Closed
NalaGinrut opened this issue May 3, 2020 · 12 comments · Fixed by #24
Closed

Name resolution #16

NalaGinrut opened this issue May 3, 2020 · 12 comments · Fixed by #24
Labels

Comments

@NalaGinrut
Copy link
Contributor

The resolution rules are not well documented in Rust doc, the rustc relies on librustc_resolve.

I'm going to list all the rules here (or wiki) for the reference.

@NalaGinrut
Copy link
Contributor Author

NalaGinrut commented May 3, 2020

  • Traverse AST top-down and resolve every encountered name.
  • The situation that new scope should be added:
    • A block enclosing with curly braces
    • Let binding
    • Hygiene macro
  • The rustc introduced a concept of Ribs to include all these kinds of scopes. Each Ribs maintain its own stack for storing the scopes. I think this can be implemented by a base class Scope. Maybe we don't have to reinvent a new concept.
  • These items have their own namespace, so the identifier is NOT unique among them:
    • Types
    • Values
    • Macros.

@bjorn3
Copy link

bjorn3 commented May 3, 2020

The RFC for the current name resolution is: https://github.com/rust-lang/rfcs/blob/master/text/1560-name-resolution.md

@NalaGinrut
Copy link
Contributor Author

Oh nice! That's what we need, I googled an obsoleted result. Thanks!

@NalaGinrut
Copy link
Contributor Author

NalaGinrut commented May 5, 2020

I think we should also add an option to dump the AST after the resolution, for debugging the resolution.

@philberty
Copy link
Member

I agree we can reuse the same command line option and i think dumping to file would be really helpful aswell lets makea new issue to dump to file instead of console

@bjorn3
Copy link

bjorn3 commented May 5, 2020

Rustc has several versions of this: rustc -Zunpretty=help

@NalaGinrut
Copy link
Contributor Author

NalaGinrut commented May 5, 2020

@bjorn3 nice to know it, however, -Z seems only for nightly.

@philberty If you just want to output the current result to a file with an option, I think it's just a few lines code. It's possible to refactor the current dump framework to support multiple dump format, and even for a different stage of the pipeline, but I don't think it's our current work. Anyway it's a good idea to add to TODO.

@NalaGinrut
Copy link
Contributor Author

The resolution relies on macro expansion, so I'm starting to work on macros parallelly. #17

@philberty philberty linked a pull request May 17, 2020 that will close this issue
@philberty philberty reopened this May 20, 2020
@philberty
Copy link
Member

Sorry for the closed issues i wanted to see if tagging commits linked them to issues but it seems to just close them instead

@philberty philberty added the plan label Dec 18, 2020
@philberty philberty added this to the Core Datastructures milestone Dec 18, 2020
@philberty philberty removed this from the Core Datastructures milestone Jan 6, 2021
philberty pushed a commit that referenced this issue Mar 3, 2021
This adds implementation for the optabs for complex operations.  With this the
following C code:

  void g (float complex a[restrict N], float complex b[restrict N],
	  float complex c[restrict N])
  {
    for (int i=0; i < N; i++)
      c[i] =  a[i] * b[i];
  }

generates

NEON:

g:
        vmov.f32        q11, #0.0  @ v4sf
        add     r3, r2, #1600
.L2:
        vmov    q8, q11  @ v4sf
        vld1.32 {q10}, [r1]!
        vld1.32 {q9}, [r0]!
        vcmla.f32       q8, q9, q10, #0
        vcmla.f32       q8, q9, q10, #90
        vst1.32 {q8}, [r2]!
        cmp     r3, r2
        bne     .L2
        bx      lr

MVE:

g:
        push    {lr}
        mov     lr, #100
        dls     lr, lr
.L2:
        vldrw.32        q1, [r1], #16
        vldrw.32        q2, [r0], #16
        vcmul.f32       q3, q2, q1, #0
        vcmla.f32       q3, q2, q1, #90
        vstrw.32        q3, [r2], #16
        le      lr, .L2
        ldr     pc, [sp], #4

instead of

g:
        add     r3, r2, #1600
.L2:
        vld2.32 {d20-d23}, [r0]!
        vld2.32 {d16-d19}, [r1]!
        vmul.f32        q14, q11, q9
        vmul.f32        q15, q11, q8
        vneg.f32        q14, q14
        vfma.f32        q15, q10, q9
        vfma.f32        q14, q10, q8
        vmov    q13, q15  @ v4sf
        vmov    q12, q14  @ v4sf
        vst2.32 {d24-d27}, [r2]!
        cmp     r3, r2
        bne     .L2
        bx      lr

and

g:
        add     r3, r2, #1600
.L2:
        vld2.32 {d20-d23}, [r0]!
        vld2.32 {d16-d19}, [r1]!
        vmul.f32        q15, q10, q8
        vmul.f32        q14, q10, q9
        vmls.f32        q15, q11, q9
        vmla.f32        q14, q11, q8
        vmov    q12, q15  @ v4sf
        vmov    q13, q14  @ v4sf
        vst2.32 {d24-d27}, [r2]!
        cmp     r3, r2
        bne     .L2
        bx      lr

respectively.

gcc/ChangeLog:

	* config/arm/iterators.md (rotsplit1, rotsplit2, conj_op, fcmac1,
	VCMLA_OP, VCMUL_OP): New.
	* config/arm/mve.md (mve_vcmlaq<mve_rot><mode>): Support vec_dup 0.
	* config/arm/neon.md (cmul<conj_op><mode>3): New.
	* config/arm/unspecs.md (UNSPEC_VCMLA_CONJ, UNSPEC_VCMLA180_CONJ,
	UNSPEC_VCMUL_CONJ): New.
	* config/arm/vec-common.md (cmul<conj_op><mode>3, arm_vcmla<rot><mode>,
	cml<fcmac1><conj_op><mode>4): New.
@philberty
Copy link
Member

Closing this as there is documentation available over on the wiki for name resolution

@bjorn3
Copy link

bjorn3 commented Mar 15, 2021

Did you forget to close this?

@philberty
Copy link
Member

Thanks, Again we are following rustc more documentation will be added to the wiki over time. See -frust-dump-all for debug outputs and this diagram.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants